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Managementuittreksel 
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Na  het  pionier-project  SIMNET  van  DARPA  {Defense  Advanced  Research  Project 
Agency)  is  omstreeks  1990  in  de  Verenigde  Staten  een  proces  in  gang  gezet  om  het 
concept  van  het  koppelen  van  interactieve  simulatoren  technisch  verder  te  onder- 
zoeken  en  exploreren,  en  **  om  interoperabiliteit  tussen  de  heterogene  simulatoren 
te  realiseren  standaarden  te  ontwikkelen  om  een  gemeenschappelijke  ‘taaP  voor 
de  communicatie  tussen  de  simulaties  te  definieren.  De  drijvende  kracht  achter  het 
concept  ‘DIS’  {Distributed  Interactive  Simulation)  en  het  proces  ‘DIS- Workshops’ 
was  in  eerste  instantie  de  US  Army  en  DARPA;  sinds  haar  oprichting  in  1992 
daarnaast  ook  het  DMSO  {Defense  Modeling  and  Simulation  Office). 

Aan  het  DIS-concept  liggen  twee  principes  ten  grondslag: 

1 .  de  interacties  tussen  de  simulatoren  worden  gerealiseerd  door  het  zenden  van 
vast  gedefinieerde  boodschappen  (Protocol  Data  Units:  PDU’s); 

2.  de  simulatoren  werken  in  real-time,  gesynchroniseerd  met  de  muurklok.  De 
PDU’s  worden  naar  alle  andere  simulatoren  gestuurd,  waar  ze  met  minimale 
vertraging  ontvangen  en  verwerkt  moeten  worden. 

In  September  1996  werd  de  15^  en  laatste  DIS  Workshop  gehouden.  Niet  de  laatste 
omdat  het  werk  af  is,  maar  omdat  DMSO  op  een  andere  leest  wil  doorgaan 
(technisch  en  organisatorisch).  Weliswaar  zijn  thans  met  de  serie  IEEE  1278 
standaarden  belangrijke  mijlpalen  bereikt,  maar  de  laatste  tijd  werden  de  geluiden 
die  de  beperkingen  van  DIS  uitten  steeds  luider. 

De  beperkingen  van  de  DIS-protocollen  zijn: 

•  schaalbaarheid:  voor  oefeningen  met  grotere  aantallen  entiteiten  (bijv.  boven 
bataljonsniveau)  zijn  er  technische  limitaties  m.b.t.  de  verwerkingscapaciteit 
van  simulatoren  voor  de  PDU’s  en  de  communicatie-bandbreedte; 

•  betrouwbaarheid:  in  verband  met  de  vereiste  minimale  vertraging  tussen  ver- 
zend-  en  ontvangst-tijdstip  van  de  data  worden  niet-volledig  betrouwbare  com- 
municatie-protocollen  gebruikt.  Voor  sommige  berichten  erf  berichtenstromen  is 
dat  minder  acceptabel; 

•  flexibiliteit:  de  rigide,  vast  gedefinieerde  data-formaten  van  de  PDU’s  bieden 
weinig  flexibiliteit; 


TN  0-rapport 


FEL-96-A273 


3 


•  tiidmanagement:  voor  vele  andere  vormen  van  koppeling  tussen  gedistribueerde 
simulaties  zijn  andere  vormen  van  tijd-management  en  -synchronisatie  noodza- 
kelijk  (bijv.  bij  event-driven  wargames  en  bij  simulaties  voor  analyse). 

Om  hierin  tegemoet  te  komen  (en  interoperabiliteit  tussen  simulaties  en  hergebruik 
van  simulaties  te  bevorderen),  heeft  DMSO  het  High  Level  Architecture  (HLA) 
initiatief  gestart.  Prototype-ontwikkelingen  werden  ca.  18  maanden  geleden  door 
DMSO  gestart.  In  September  j.l.  werd  over  de  resultaten  van  de  proto-federations 
gerapporteerd.  Hart  van  de  HLA  is  de  Run  Time  Infrastructure  (RTI,  een  zoge« 
naamde  Application  Programmer's  Interface),  via  welke  de  simulatoren/simulaties 
communiceren  en  waarvoor  een  formele  Interface  Specification  geldt.  Uit  deze 
rapportages  springt  naar  voren  dat  de  functionaliteit  van  de  RTF  Interface  Specifi¬ 
cation  voor  de  verschillende  simulatie-domeinen  voldoet,  maar  dat  de  vertragingen 
voor  real-time,  man-in-the-loop  platform  simulatoren  (nog)  te  groot  zijn.  Optimali- 
satie  in  dat  opzicht  is  noodzakelijk. 

In  dat  verband  zijn  ook  de  ontwikkelingen  van  belang  in  het  DARPA/USACOM- 
project:  Synthetic  Theatre  of  War  '97,  waarin  een  Joint  Task  Force  oefening 
gespeeld  gaat  worden  met  10,000  -  100.000  objecten.  In  STOW  worden  zeer  veel 
‘HLA/RTF-technieken  toegepast,  respectievelijk  ontwikkeld, 

Het  HLA-initiatief  (als  uitvloeisel  van  DoD’s  Modeling  and  Simulation  Master- 
plan)  resulteerde  voorts  in  een  Memorandum  van  de  Under  Secretary  of  Defense 
for  Acquisition  and  Technology,  gedateerd  10  September  1996,  waarin  HLA  als  de 
architectuur  wordt  aangewezen  voor  alle  simulaties  in  de  DoD  (zie  Bijlage  A). 

Los  van  de  technische  pro’s  en  contra’s  van  HLA  versus  DIS  zal  een  van  de  reper- 
cussies  van  dit  mandaat  zijn,  dat  op  termijn  ook  de  industriele  ondersteuning  van 
de  DIS  IEEE  1278  standaarden  zal  gaan  wegebben  door  het  wegvallen  van  een 
belangrijke  markt  in  de  toepassing  ervan.  Voor  toekomstige  (simulatie)systemen  - 
en  zeker  die  met  een  groeipotentieel  -  is  het  zaak  om  de  blik  naar  HLA  te  richten. 

Het  rapport  geeft  een  overzicht  van  de  DIS  protocollen  en  de  standaardisatie  ervan 
en  gaat  in  detail  in  op  de  High  Level  Architecture. 
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1.  Introductie 

1.1  Inleiding 

Dit  rapport  is  een  (tussen)rapportage  van  het  project  ‘Kennisonderhoud  DIS/HLA’ 
(A95KL841)  en  een  vervolg  op  eerdere  rapportages,  presentaties  en  demonstraties 
over  het  onderwerp  Advanced  Distributed  Simulation  Technology. 

In  het  afgelopen  jaar  hebben  zich  in  het  onderwerp  Distributed  Interactive  Simu¬ 
lation  ontwikkelingen  voltrokken  die,  althans  in  de  ‘DIS  community’,  nogal  wat 
stof  hebben  opgetrokken.  De  belangrijkste  ontwikkeling  is  wel  het  High  Level 
Architecture  (HLA  )  initiatief  van  het  US  DoD  Defense  Modeling  and  Simulation 
Office  (DMSO).  Dit  initiatief,  medio  1995  gestart,  resulteerde  o.a.  in  een  Memo¬ 
randum  van  de  Under  Secretary  of  Defense  for  Acquisition  and  Technology, 
gedateerd  10  September  1996,  waarin  HLA  als  de  architectuur  wordt  aangewezen 
voor  alle  simulaties  in  de  DoD  (zie  Bijlage  A). 

In  hoofdstuk  3  wordt  in  technische  zin  nader  op  de  HLA  ingegaan  en  op  de  rede- 
nen  ervoor. 


1.2  DIS  Workshop  evolutie 

De  standaardisatie  van  Distributed  Interactive  Simulation  vindt  zijn  bron  in  de 
Workshops  for  Standards  for  the  Interoperability  of  Distributed  Simulations, 
welke  twee  keer  per  jaar  in  Orlando,  FL  worden  gehouden.  In  September  1996 
werd  de  15e  Workshop  gehouden,  welke  de  laatste  was  conform  de  opzet  zoals  die 
in  het  verleden  is  gegroeid. 

In  februari  ‘96  vormde  de  DIS  Steering  Committee  de  Special  Task  Group:  Vision 
Implementation  Plan  (STGVIP),  om  een  plan  te  schetsen  voor  de  implementatie 
van  de  DIS  Vision*  in  het  licht  van  de  ontwikkeling  van  de  HLA  en  de 
"Interoperability  lessons  learned  of  the  DIS  community  *K 
De  structuur  en  werkwijze  tot  nu  toe  was  dat,  op  aansturing  door  een  Steering 
Committee  (bestaande  uit  een  Coordinating  Committee,  Technical  Committee  en 
User  Sponsor  Committee),  een  groot  aantal  werkgroepen  (WGs),  subwerkgroepen 
(SWGs),  special  interest  groups  (SIGs)  en  focus  groups  (FGs)  voomamelijk  tijdens 
de  workshops  actief  was.  Op  basis  van  ingediende  en  gepresenteerde  Position 
Papers  werden  werden  zaken  besproken,  consensus  bereikt,  ontwerp  standaarden 
voorbereid  en  voor  standaardisatie  (ballot  en  approval)  aan  IEEE  voorgelegd. 

Thans  is,  naar  aanleiding  van  de  omarming  van  HLA,  een  DIS  Transition  gaande 
naar  een  andere  structuur  en  werkwijze.  Een  en  ander  is  nog  niet  uitgekristalliseerd 
maar  de  belangrijkste  verschillen  zijn  dat  er  een  wat  grotere  scheiding  komt  tussen 
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Zie  ook  Bijlage  D:  'The  Way  Ahead.. "  (maart  1996) 
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een  periodieke  Conference  en  de  Standards  Activity,  Vanuit  de  Conference  zulien 
behoeften  geuit  kunnen  worden  naar  de  standaardisatie  activiteit.  Duidelijk  is  wel 
dat  de  DoD  naar  een  meer  efficient  standaardisatie-proces  wil  (met  gecontracteer- 
de  werkzaamheden).  De  Conference  zou  op  termijn  financieel  self-supporting 
moeten  worden. 

De  Standards  Development  Groups  die  momenteel  voorzien  worden,  zijn: 

•  Architecture  SDG 

•  Interface  SDG 

•  Object  Model  Template  SDG 

•  Federation  Execution  Development  Process  SDG,  en 

•  Protocol  Catalog  SDG 

De  SDG’s  dienen  de  volgende  initiele  DIS++  IEEE  producten  op  te  leveren: 

-  een  overkoepelende  DIS++  Architecture  (IEEE  xxxx  Standard) 

-  Interface  Specification  (xxxx.l  Standard) 

-  Object  Model  Template  (xxxx.2  Standard) 

-  Federation  Execution  Development  Process  (xxxx. 3  Recommended  Prac¬ 
tice). 

Daamaast  wordt  er  over  gesproken  om  SEDRIS  (Synthetic  Environment  Data 
Representation  Interchange  Specification)  als  een  lEEE-standaard  te  ontwikkelen. 

Voor  de  Conferences^  wordt  gedacht  aan  de  volgende  forums  en  aandachtsgebie- 
den: 

•  User  Community  Forums 

-  Analysis  Forum 

-  Research,  Development  and  Engineering  Forum 

-  Test  and  Evaluation  Forum 

-  Small  Team  Training  Forum 

-  Staff-Level  Training  Forum 

•  Speciality  Area  Forums 

-  Infrastructure  track 

-  Run-Time  Infrastructure  Forum 

-  Communication  Architecture  Forum 

-  Live  Interaction  Forum 

-  Environment  track 

-  Simulated  Environment  Forum 

-  Sensor  Modeling  Forum 

-  Command,  Control  and  Communications  track 

-  C4ISR  Forum 


2 


De  conferences  gaan  heten:  199x  Spring/Fall  Simulation  Interoperability  Work¬ 
shop',  evenzo  de  SDGs:  Simulation  Interoperability  Standards  Organization, 
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-  Federation  Development  track 

-  Federation  Development  Process  Forum 

-  Exercise  Management  Forum 

-  VV&AForum 

-  Testing  Forum 

-  Applications  track 

-  Federation  Implementors’  Workshop 

-  VehicleAVeapon  System  Modeling  Forum 

-  Human  Decision-making  and  Behavior  Representation  Forum 

-  Logistics  Forum 


In  Bijlage  C  “DIS++  Transition  Frequently  Asked  Questions”  (nov,  ‘96)  wordt 
meer  informatie  gegeven. 
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2.  DIS  standaardisatie  en  protocollen 

2.1  IEEE-1278  standaarden 

De  primaire  doelstelling  van  de  DIS  Workshops  is  de  ontwikkeling  van  (civiele) 
standaarden  voor  interacties  tussen  gedistribueerde  interactieve  (real-time)  simu- 
laties.  De  volgende  lEEE-documenten  zijn,  dan  wel  worden  ontwikkeld: 

•  IEEE  1278.1-1995:  Standard  for  Distributed  Interactive  Simulation  -  Applica¬ 
tion  Protocols; 

•  IEEE  1278.2:  Standard  for  Distributed  Interactive  Simulation  -  Communication 
Services  &  Profiles  Requirements; 

•  IEEE  1278.3:  Standard  for  Distributed  Interactive  Simulation  -  Exercise  Ma¬ 
nagement  and  Feedback  Recommended  Practices; 

•  IEEE  1278.4:  Recommended  Practice  for  Distributed  Interactive  Simulation 
(DIS)  ”  Verification,  Validation  &  Accreditation; 

•  IEEE  1278.5:  Standard  for  Distributed  Interactive  Simulation  -  Fidelity  Des¬ 
cription  Requirements. 

De  laatste  twee  in  bovenstaande  lijst  zijn  nog  geen  lEEE-standaard,  maar  zouden 
dat  in  *97  moeten  worden.  Naast  de  lEEE-documenten  zijn  er  ook  Rationales, 
welke  achtergrondsinformatie  geven. 

De  belangrijkste  van  genoemde  documenten  is  wel  de  Application  Protocols  (IEEE 
1278.1).  Hierin  worden  twee  conceptuele  interactie-niveaus  tussen  entiteiten  / 
objecten  gedefinieerd: 

•  welke  informatie  tussen  de  simulaties  uitgewisseld  moet  worden  en  onder 
welke  omstandigheden  (Protocol  Data  Units) 

•  data  represen tatie  formaten:  hoe  de  status  variabelen  en  andere  attributen  van 
elke  entiteit  gerepresenteerd  worden  in  deze  interacties, 

De  feitelijke  communicatieprotocollen  (d.i.:  hoe  de  vereiste  informatie  verzonden 
wordt  tussen  de  simulaties)  wordt  in  IEEE  1278.2  gespecificeerd. 
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De  1278.1-standaard  heeft  de  volgende  ontwikkelingsgang: 

-  DIS  versie  1.0  van  mei  1992; 

-  ffiEE  1278  (maart  1993); 

-  DIS  versie  2.0.3  (September  1993); 

-  IEEE  1278.1-1995  /  "DIS  versie  2.0.4”  (September  1995); 

-  DIS  versie  2.1.1  working  draft  (maart  1995); 

-  DIS  versie  2,1.4  working  draft  (September  1996); 

-  IEEE  1278.1-1997  Annex  (September  1997).*^ 

In  relatie  met  de  Application  Protocols  is  ook  van  belang  het  document  Enumera¬ 
tion  and  Bit-encoded  Values  for  use  with  LE.E.E.  1278 J,  Vanwege  het  dynami- 
sche  karakter  van  dit  document  wordt  hier  geen  lEEE-standaard  van  gemaakt. 
Versiebeheer  en  Change  requests  worden  onder  verantwoordelijkheid  van  de 
voorzitter  van  de  Protocol  Working  Group  door  het  Institute  for  Simulation  and 
Training  uitgevoerd.  Recentelijk  zijn,  als  onderdeel  van  het  creeren  van  een  Data 
Dictionary  and  Protocol  Catalog,  de  enumeraties  ook  in  een  MS  Access  database 
beschikbaar.  Onderhoud  hiervan  is  nog  onduidelijk. 

Als  onderdeel  van  de  (HLA)  Protocol  Catalog  (zie  paragraaf  1.2),  waarvoor 
DMSO  verantwoordelijkheid  neemt,  is  wel  een  activiteit  gestart  om  de  DIS  PDU’s 
en  enumeraties  om  te  zetten  in  een  zgn.  PnP-FOM  {Plug-and-Play  Federation 
Object  Model  zie  ook  paragraaf  3.2),  om  de  geinvesteerde  kennis  in  DIS  te  be- 
schermen  en  de  redesign  van  simulatoren  naar  HLA-compliancy  te  vergemakkelen. 


2.2  De  Protocol  Data  Units  (PDUs) 

De  IEEE  1278  (DIS  versie  1)  omvatte  de  volgende  PDU’s: 

•  Entity  State 

•  Fire 

•  Detonation 

•  Collision,  en 

•  een  zestal  PDU’s  voor  logistieke  functies  (Service  Request,  Resupply  Offer, 
Resupply  Received,  Resupply  Cancel,  Repair  Complete,  Repair  Response). 

De  1278.1-1995  (DIS  versie  2.0)  voegde  daaraan  toe: 

•  Simulation  Management  PDU’s  (12  PDU’s:  Create  Entity,  Remove  Entity, 
Start/Resume,  Stop/Freeze,  Set  Data,  Data,  Data  Query,  Acknowledge,  Action 
Request,  Action  Response,  Event  Report,  Message) 

•  Radio  (Transmitter,  Signal,  Receiver) 

•  Emissions  (Electronic  Emission,  Designator) 


^  Vanaf  September  ‘96  geeft  DMSO  geen  funding  meer  voor  “IEEE  1278“  gerela- 
teerde  activiteiten,  maar  het  DIS++  Transition  Committee  heeft  uitgesproken  dat 
deze  vervolgd  en  per  September  ‘97  afgerond  zullen  zijn:  “Ending  the  Job”. 


TNO-rapport 


FEL-96*A273 


10 


A1  geruime  tijd  is  gestudeerd  op  verdere  functionele  uitbreiding  van  interacties. 

Deze  PDU’s  zou  de  DIS  2.1-serie  genoemd  kunnen  worden.  Thans  ligt  in  vrijwel 

gerede  versie  DIS  2.1.4  voor.  Deze  worden  een  Annex  aan  de  IEEE  1278.1-1995 

standaard.  Het  betreft  de  volgende  protocollen: 

•  Collision-elastic;  een  protocol  voor  botsingen,  trekken,  slepen,  waarin  (met 
gebruikmaking  van  de  wetten  van  Newton)  high  fidelity  interacties  tussen  twee 
gesimuleerde  entiteiten  mogelijk  zijn  (overdracht  van  lineair-  en  rotatie- 
moment,  variabele  elasticiteit,  overdracht  van  moment  als  functie  van  opper- 
vlakte-standhoeken). 

•  Minefield  protocollen  (Minefield  PDU,  Mines  PDU,  Minefield  State  PDU, 
Minefield  Query  PDU,  Minefield  Data  PDU),  waarmee  met  verschillende  mate 
van  detail,  informatie  over  mijnvelden  en  mijnen  gecommuniceerd  wordt. 

•  Entity  State  Update:  een  protocol,  waarmee  slechts  de  niet-statische  informa¬ 
tie  van  een  entiteit  wordt  gecommuniceerd,  waardoor  een  reductie  van  beno- 
digde  communicatie-bandbreedte  te  bereiken  is. 

•  Simulation  Management  w/Reliability:  de  PDU’s  worden  in  principe,  con¬ 
form  IEEE  1278.2  met  het  ‘best  effort’  UDP/IP  protocol  verstuurd  (d.w.z.  zon- 
der  garantie  voor  correcte  ontvangst).  Voor  het  merendeel  van  de  te  verzenden 
data  is  dat  acceptabel,  maar  voor  een  aantal  Simulation  Management  PDUs 
(Start,  Stop,  Set  Data,  etc.)  kan  een  hoge  betrouwbaarheid  noodzakelijk  zijn. 

•  IFF/ATC/NAVAIDS:  om  informatie  te  communiceren  m.b.t.  functies  zoals 
cooperatieve  IFF-systemen,  Air  Traffic  Control  Beacons  en  Transponders  en 
andere  navigatiesystemen. 

•  Underwater  Acoustic:  t.b.v.  de  informatie  overdracht  omtrent  passieve  en 
actieve  akoustische  emissies. 

•  Intercom  (Intercom  Control  en  Intercom  Signal):  t.b.v.  intercom  communicatie 
in  DIS  oefeningen.  Dit  protocol  ondersteunt  (met  overdracht  van  digitale  data) 
de  conversatie  tussen  twee  partijen  en  tussen  meerdere  partijen  gelijktijdig.  De 
Intercom  Signal  PDU  is  in  feite  exact  gelijk  aan  de  Signal  PDU  van  het  Radio 
protocol. 

•  Entity  Management  (Aggregate  (Aggregate  State,  Action  Request,  Action 
Response,  Event  Report),  Entity  Handover,  IsPartOf,  IsGroupOf):  voor  het  be- 
sturen  van  entity  aggregate  activiteiten,  de  overdracht  van  de  ownership  van 
een  entiteit  tussen  verschillende  simulaties  en  om  een  hierarchisch  verband  aan 
te  geven  tussen  separaat  gesimuleerde  entiteiten  (zoals  bijv.  een  missile  dat  aan 
de  vleugel  van  een  een  vliegtuig  hangt,  maar  na  lancering  een  ‘eigen  leven’ 
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leidt). 

•  Environment  (Environmental  Process,  Gridded  Data,  Point  Object  State, 
Linear  Object  State,  Areal  Object  State):  protocollen  om  veranderingen  in  de 
gesimuleerde  omgeving  tijdens  de  oefening  te  communiceren.  De  eerste  twee 
(met  minder,  respectievelijk  meer  resolutie)  t.b.v.  meteorologische  veranderin¬ 
gen  (wind,  rook,  heiigheid,  zonnestand,  etc.),  de  Object  State  PDUs  t.b.v.  ver¬ 
anderingen  aan  (vaste)  objecten  in  de  synthetische  omgeving/terrein,  Het  ge- 
bruik  van  deze  protocollen  vergt  overigens  ook  een  Environment  Server  om  de 
wijzigingen  bij  te  houden  /  te  beheren. 

•  Non-Real  Time  Protocol:  een  protocol  om  in  de  simulaties  de  tijd  sneller  of 
langzamer  dan  de  muurklok  te  laten  lopen. 

•  Field  Instrumentation:  ten  behoeve  van  geinstrumenteerde  life  systemen.  Bij 
dergelijke  systemen  is  o.a.  de  communicatie-bandbreedte  (via  radiokanalen) 
een  bottleneck.  De  Field  Instrumentation  PDU’s  is  een  set  van  protocollen  (met 
ingeperkte  functionaliteit),  die  in  de  plaats  treedt  van  alle  hiervoor  genoemde 
protocollen.  Karakteristiek  is  bijvoorbeeld  de  TSPI-PDU,  waarin  Time,  Space 
en  Position  informatie  van  een  entiteit  gecommuniceerd  wordt,  Hierbij  kan  de 
PDU  van  variabele  lengte  zijn,  omdat  niet  alle  informatie  in  elke  broadcast 
aanwezig  behoeft  te  zijn. 


2.3  Ending  the  job 

De  hiervoor  vermelde  PDU’s  vormen  een  tamelijk  complete  set  van  protocollen 
om  (real-time  voor  menselijke  perceptie)  de  gebeurtenissen  in  een  synthe- 
tisch/virtueel  gevechtsveld  te  beschrijven  en  de  interacties  tussen  gesimuleerde 
wapenplatformen  te  specificeren.  Vele  van  deze  PDU’s  zijn  ontstaan  uit  de  func- 
tionele  behoefte  in  het  project  Close  Combat  Tactical  Trainer  (CCTT)  van  de 
USArmy.  Op  een  aantal  van  deze  protocollen  dient  ook  bij  TNO-FEL  de  kennis  en 
ervaring  verdiept  te  worden.  Met  name  geldt  dit  voor  Radio,  Intercom,  Environ¬ 
ment  (dynamische  veranderingen  in  het  synthetische  terrein). 

In  het  licht  van  de  onder  1 .2  vermelde  omarming  van  HLA  zal  een  verdere  opti- 
malisatie  van  de  DIS-standaarden  waarschijnlijk  niet  plaatsvinden.  Wei  wordt  de 
in  de  DIS-community  opgebouwde  kennis  meegenomen  in  het  HLA-vervolg  tra- 
ject.  Het  noodzakelijke  beheer  van  de  bij  de  PDU’s  behorende  Enumerations  and 
Bit-Encoded  Values  is  een  probleem,  omdat  dit  niet  bij  lEEEis/wordt  ingebracht 
en  DoD  geen  financiering  meer  geeft  voor  DIS-georienteerde  zaken. 
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3.  High  Level  Architecture 

3.1  Inleiding 


Het  US  Defense  Modeling  and  Simulation  Office  (DMSO)  heeft  de  opdracht 
gegeven  tot  de  ontwikkeling  van  standaarden  ter  ondersteuning  van  alle  Modeling 
en  Simulation  activiteiten  binnen  het  US  DoD  (Department  of  Defense).  Dit  heeft 
geleid  tot  de  ontwikkeling  van  de  High  Level  Architecture,  een  architectuur  die  als 
basis  zal  dienen  voor  alle  toekomstige  gedistribueerde  simulatie  applicaties.  Het 
doel  van  de  HLA  is  tweeledig: 


1.  Interoperabiliteit  tussen  simulatiemodellen: 

Het  is  zeer  wenselijk  simulatiemodellen  uit  verschillende  gebruikersdomeinen 
te  integreren  in  een  gezamenlijk  scenario.  B.v.  de  integratie  van  real-time,  man- 
in-the-loop  platform  simulatie  met  wargame-achtige,  event-driven  simulatie.  De 
situatie  op  dit  moment  is  dat  deze  simulaties  niet  op  elkaar  aan  te  sluiten  zijn, 
aangezien  de  eerst  genoemde  groep  simulaties  gebruik  maakt  van  het  DIS- 
protocol  (Distributed  Interactive  Simulation)  en  de  tweede  groep  van  het  ALSP- 
protocol  (Aggregated  Level  Simulation  Protocol).  HLA  combineert  de  voorde- 
len  van  beide  standaarden. 

2.  Hergebruik  van  simulatie  modellen: 

Door  standaarden  te  definieren  die  verder  gaan  dan  het  vastleggen  van  een  net- 
werk  protocol  en  die  als  het  ware  de  architectuur  van  alle  simulatie  modellen 
vastleggen,  wordt  hergebruik  van  bestaande  modellen  eenvoudiger,  met  name 
door  de  object-georienteerde  opzet  van  het  HLA. 

In  augustus  ‘96  is  een  HLA  baseline  opgeleverd.  Deze  eerste  versie  is  vrij  ver- 
krijgbaar  binnen  de  US,  maar  nog  niet  voor  buitenlanders.  Deze  baseline  bevat  de 
volgende  componenten: 

1.  RTI  prototype: 

De  Run-Time  Infrastructure  (RTI)  is  een  implementatie  van  een  gedistribueerde 
systeem-  en  interconnectielaag,  die  als  basislaag  dient  voor  alle  HLA  applica¬ 
ties.  Deze  laag  verzorgt  de  communicatie  tussen  alle  simulatiemodellen. 

2.  Interface  Specification: 

De  Interface  Specification  is  een  formele,  functionele  beschrijving  van  het  in¬ 
terface  tussen  enerzijds  de  HLA  applicatie  (b.v.  een  tanksimulator)  en  ander- 
zijds  de  RTI. 

3.  Rules: 

Een  verzameling  van  technische  principes  en  afspraken  waaraan  HLA  deelne- 
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mers  zich  moeten  houden  om  HLA-compatible  te  zijn. 

4,  Object  Model  Templates  (OMT): 

De  Object  Model  Templates  zijn  gestandaardiseerde  formaten  die  gebruikt 
worden  om  de  functionaliteit  van  simulatiemodellen  vast  te  leggen  alsmede  de 
interactie  tussen  deze  modellen.  Op  deze  manier  wordt  voor  de  oefening  vast- 
gelegd  wat  de  'capabilities'  van  alle  deelnemende  simulatiemodellen  zijn  en 
welke  interactie/interpretatie  van  de  gegevens  kan  plaatsvinden  (b,v.  resolutie, 
wel/geen  voice).  Tijdens  de  oefening  mag  niet  worden  afgeweken  van  deze 
specificaties  omdat  andere  deelnemende  simulaties  anders  de  ontvangen  infor- 
matie  niet  kunnen  verwerken. 


Deze  componenten  worden  in  de  paragraaf  Status  verder  beschreven. 


HLA  Application 
Tank  Simulator 


HLA  Application 
Data  Logger 


Figuur  1:  RTI  gedistribueerde  commiinicatielaag. 


3.2  Architectuur 

Alvorens  de  architectuur  van  HLA  nader  toe  te  lichten,  omschrijven  we  eerst  een 
aantal  termen: 

Federate 

HLA-compatible  applicatie  zoals  simulatoren,  data  collectors,  semi-automatic 
forces,  simulation  management  tools  en  presentatiegereedschappen  zoals  3D- 
Stealth  en  Audio  servers. 

Federation 

Verzameling  van  participerende  federates.  Deze  federates  moeten  zich  houden  aan 
de  Federation  Object  Model  die  voor  deze  federation  is  opgesteld. 
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Federation  Object  Model  (FOM) 

Contract  tussen  federates  die  alle  toegestane  interacties  tussen  de  federates  vast- 
legt.  Het  beschrijft  dus  op  hoog  niveau  de  interface  tussen  alle  applicaties. 

Simulation  Object  Model  (SOM) 

De  SOM  specificeert  de  ‘capabilities’  van  een  federate.  Met  andere  woorden:  wat 
is  de  functionaliteit  van  de  applicatie,  Deze  opzet  bevordert  hergebruik  van  reeds 
bestaande  simulatiemodellen. 

Object 

Entiteit  met  unieke  identificatie  binnen  de  federation.  Denk  b.v.  aan  simulatie¬ 
modellen  van  tanks  en  vliegtuigen.  Objecten  hebben  een  status  die  bepaald  wordt 
door  de  huidige  waarden  van  hun  attributen.  Objecten  interacteren  met  ander 
objecten  zoals  formed  vastgelegd  is  in  de  FOM,  Dit  kan  door  middel  van  interac¬ 
tions  (berichten  die  van  object  naar  object  worden  gestuurd)  of  door  het  distribue- 
ren  van  object  attributen. 

Attribute 

Element  van  een  object.  B.v.  voor  een  tankobject  zijn  positie,  snelheid  en  orienta- 
tie  attributen.  De  attributen  vormen  samen  de  status  van  het  object.  Andere  objec¬ 
ten  kunnen  attribuutwaarden  van  een  object  opvragen. 

Interaction 

Objecten  kunnen  elkaar  berichten  toesturen  via  interactions.  Als  een  tanksimulator 
bijvoorbeeld  vuurt,  zal  hij  dit  door  middel  van  een  interaction  aan  de  buitenwereld 
bekend  maken. 

Federation  execution 

Het  verloop  van  de  federation  oefening  (session).  Schematisch  ziet  het  er  als  volgt 
uit: 


Federation  Execution 


Figuur  2:  Federation  Execution, 
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De  federation  bestaat  uit  een  aantal  federates  (F)  die  een  aantal  objecten  (O) 
geinstantieerd  hebben,  zoals  in  de  FOM  en  SOMs  is  vastgelegd.  Deze  objecten 
communiceren  via  interactions  en  kunnen  ook  elkaars  attributen  benaderen.  Elk 
object  attribute  wordt  door  een  federate  beheert,  m.a.w,  deze  federate  is  de  eige- 
naar.  Alleen  de  eigenaar  kan  de  attribute  waarde  veranderen,  anderen  kunnen  de 
waarde  alleen  lezen.  Zo  kan  het  zijn  dat  attribute  A  van  object  1  van  federate  F  is, 
terwijl  attribute  B  van  hetzelfde  object  door  federate  G  wordt  ingevuld,  Het  is  ook 
mogelijk  ‘ownership’  aan  andere  federates  over  te  geven. 

Het  HLA  biedt  via  de  Run-Time  Infrastructure  (RTI)  de  volgende  functionaliteit 
aan  de  HLA  applicaties: 

1.  Federation  Management  services: 

Federates  hebben  de  volgende  middelen  voor  simulation  management-achtige 
acties. 

•  Create/destroy  execution 

Het  creeren  of  verwijderen  van  federation  executions.  Alleen  de  Federation 
Manager  (een  van  de  federates)  kan  dit  doen. 

•  Join/resign  execution 

Het  ‘inloggen’  en  ‘uitloggen’  van  een  federate  bij  een  federation  execution. 
Na  registratie  ontvangt  de  federate  alle  informatie  waarop  hij  “geabonneerd” 
is. 

•  Pause/resume  execution 

De  Federation  Manager  is  in  staat  de  execution  tijdelijk  te  onderbreken  en 
later  weer  te  hervatten. 

•  Save/restore  execution 

De  Federation  Manager  kan  de  huidige  status  van  de  federation  execution 
opslaan  en  later  weer  terugladen.  Met  name  voor  analyse  en  debriefing  doel- 
einden  is  dit  vereist. 

2.  Declaration  Management  services: 

Deze  functionaliteit  dient  om  de  netwerkbelasting  te  reduceren  en  federates  on- 
nodig  rekenwerk  te  besparen.  Dit  wordt  gerealiseerd  door  alleen  relevante  in¬ 
formatie  naar  een  federate  te  sturen.  Het  uitgangspunt  is  om  zoveel  mogelijk 
aan  de  zendende  kant  filtering  van  informatie  uit  te  voeren. 

•  Subscription 

Elke  federate  abonneert  zich  op  object  attributes  en  interactions  die  voor 
hem  van  belang  zijn.  Hij  zal  dan  daama  alleen  deze  object  informatie  (en 
relevante  wijzigingen  daarin),  ontvangen.  Subscriptions  mogen  tijdens  de 
execution  (dynamisch)  gewijzigd  worden.  Federates  kunnen  zich  niet  alleen 
abonneren  op  attribute-typen  maar  ook  op  attribute-waarden.  Zo  kan  een  fe¬ 
derate  zich  b.v.  abonneren  op  alle  entiteiten  die  zich  in  zijn  directe 
(sensor)omgeving  bevinden  op  basis  van  de  waarde  van  de  positie-attribuut. 

•  Publication 

Elke  federate  vertelt  de  federation  welke  informatie  hij  tijdens  de  execution 
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aan  zal  bieden.  Andere  federates  kunnen  zich  daar  dan  op  abonneren.  Ook 
deze  publications  kunnen  tijdens  het  verloop  van  de  simulatie-sessie  gewij- 
zigd  worden. 

3.  Object  Management  services: 

Communicatie  tussen  federates  d.m.v.  objecten  en  interactions. 

•  Instantiate/delete  object 

Een  federate  kan  objecten  bij  de  federation  registeren  en  later  weer  afmel- 
den. 

•  Update/reflect  object  attribute 

De  eigenaar  van  een  object  attribute  kan  de  waarde  veranderen.  Anderen, 
die  geabonneerd  zijn  op  dit  attribute,  ontvangen  deze  nieuwe  informatie. 

•  Request/provide  object  attribute 

Geabonneerde  federates  worden  van  veranderde  object  attributes  automa- 
tisch  op  de  hoogte  gesteld.  Een  federate  kan  echter  ook  expliciet  een  object 
attribute  opvragen,  waama  de  waarden  van  de  attribute  naar  hem  verstuurd 
zal  worden. 

•  Send/receive  interaction 

Objecten  en  federates  kunnen  ook  via  messages  met  elkaar  communiceren. 

4.  Ownership  Management  servicesj. 

Elk  object  wordt  in  principe  beheerd  door  de  federate  die  het  object  geinstanti- 
eerd  heeft.  Het  is  echter  mogelijk  de  ‘ownership’  van  attributen  over  te  dragen 
aan  andere  federates.  Een  praktisch  voorbeeld  hiervan  is  een  tanksimulator  die 
uitgerust  wordt  met  een  nieuw,  geavanceerder  bewegingsmodel.  Dit  bewe- 
gingsmodel  is  een  federate  die  eigenaar  wordt  van  de  positie-attribute  van  de 
tank  federate  en  zo  de  actuele  positie  kan  specificeren. 

5.  Time  Management  services: 

Aangezien  HLA  een  breed  scala  van  toepassingsgebieden  moet  ondersteunen 
zijn  de  hieronder  beschreven  message  ordering  methoden  gedefinieerd.  Deze 
methoden  beschrijven  hoe  de  RTI  voor  de  federate  moet  omgaan  met  binnen- 
komende  informatie,  er  van  uitgaande  dat  verstuurde  berichten  niet  altijd  in  de 
juiste  volgorde  bij  de  ontvangende  RTI  aankomen. 

•  Receive  order 

Berichten  worden  in  volgorde  van  binnenkomst  doorgegeven  aan  de  appli- 
catie.  Er  vindt  dus  geen  ordening  plaats.  Deze  methode  wordt  voomamelijk 
in  real-time,  man-in-the-loop  simulatie  toegepast. 

•  Priority  order 

Berichten  tot  een  bepaald  tijdstip  worden  op  timestamp  (d.w.z.  de  tijd  dat 
het  bericht  verzonden  is)  gesorteerd.  Dit  garandeert  niet  dat  er  later  nog  be¬ 
richten  binnen  kunnen  komen  met  een  vroegere  timestamp. 

•  Causal  order 

Bepaalde  causale  verbanden  bepalen  de  berichten- volgorde  naar  de  applica- 
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tie.  Bijvoorbeeld  de  ontvangst  van  een  detonation  event  na  de  ontvangst  van 
de  bijbehorende  fire  event, 

•  Timestamp  order 

Berichten  worden  op  timestamp  gesorteerd  met  de  garantie  dat  er  geen  be- 
richten  met  een  vroegere  timestamp  meer  binnenkomen  (lees:  worden  ver- 
werkt  door  de  RTI).  Bij  deze  methode  is  per  federate  een  look-aheadAdiCiov 
vereist,  die  aangeeft  hoelang  de  applicatie  in  de  toekomst  geen  berichten 
meer  zal  versturen.  Een  applicatie  die  een  look-ahead  van  10  seconden  spe- 
cificeert,  belooft  als  het  ware  dat  hij  de  komende  10  seconden  geen  berich¬ 
ten  zal  versturen.  Dit  geeft  vaak  een  praktisch  probleem  bij  man-in-the-loop 
simulatie  omdat  menselijk  gedrag  moeilijk  voorspelbaar  is  en  de  look-ahead 
factor  dus  0  is. 

HLA  onderscheidt  twee  orthogonale  factoren  binnen  Time  Management:  ‘paced’ 
en  ‘agreement’.  ‘Paced’  geeft  aan  of  de  federation  time  gekoppeld  is  aan  een 
muurklok.  ‘Agreement’  bepaalt  of  voor  een  tijdvoortgang  toestemming  van  de 
federation  moet  worden  gevraagd.  Deze  twee  factoren  kunnen  worden  gecombi- 
neerd  tot  vier  categorien  van  time  management: 

I  paced  with  agreement 

II  paced  with  no  agreement 

III  not  paced  with  agreement 

IV  not  paced  with  no  agreement. 

Bij  categorie  II  kan  gedacht  worden  aan  real-time,  DIS-achtige  simulaties  en  bij 
categorie  III  aan  event-driven,  ALSP-achtige  simulaties.  Bij  categorie  I  is  te  den- 
ken  aan  simulaties  voor  analyse,  waarbij  er  een  muurklok  is  en  federates  in  een 
bepaalde  volgorde  moeten  worden  opgestart.  Categorie  IV  representeert  event- 
driven  simulaties,  waarbij  elke  federate  zijn  eigen  tijdlijn  volgt,  zonder  synchroni- 
satie  (bijv.  ‘run-as-fast-as-possible’. 


Synchroon  met  muurklok 

Tijdvoortgang 

DIS  ja 

ledere  federate  onafhankelijke  tijdvoortschrijding 

ALSP  nee 

gecoordineerd 

De  federate  en  niet  de  RTI  is  verantwoordelijk  voor  het  bijhouden  van  object 
status-informatie.  De  RTI  is  slechts  een  mechanisme  om  te  communiceren  tussen 
federates  en  geeft  de  attributen  door  aan  de  federate. 


3.3  Verschillen  tussen  DIS,  ALSP  en  HLA 

Een  aantal  verschillen  tussen  DIS,  ALSP  en  HLA: 

•  DIS  en  ALSP  zijn  protocollen;  HLA  is  een  architectuur. 
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•  DIS  werkt  voomamelijk  met  niet-gegarandeerde  connectionless  communicatie 
(UDP/IP  multicast);  HLA  daarentegen  op  basis  van  connection  oriented  com¬ 
municatie  (TCP/IP  point-to-point). 

•  DIS  is  slecht  schaalbaar;  HLA  lijkt  redelijk  goed  schaalbaar  (door  declaration 
en  subscription  management), 

•  DIS  ondersteunt  real-time,  man-in-the-loop  simulatie;  HLA  generieke  simula¬ 
te. 

•  DIS  heeft  zich  reeds  bewezen;  HLA  nog  niet, 

•  DIS  standaarden  en  deliverables  zijn  commercieel  verkrijgbaar;  HLA,  d.w.z. 
RTI  implementaties,  (nog)  niet  voor  buitenlanders. 


3.4  HLA  Status 

Er  is  op  dit  moment  een  HLA  Baseline  (versie  1.0)  die  de  volgende,  in  paragraaf 

3.1  beschreven  componenten  bevat: 

1 .  RTI  prototype 

2.  Interface  Specification 

3.  Rules 

4.  Object  Model  Templates 

In  de  volgende  paragrafen  bespreken  we  de  status  en  inhoud  van  deze  afzonderlij- 
ke  componenten. 

3.4.1  RTI  prototype 

De  Run-Time  Infrastructure  (RTI)  is  een  implementatie  van  een  systeem-  en 
interconnectielaag  die  als  basislaag  zal  dienen  voor  toekomstige  HLA  applicates. 
Deze  basislaag  verzorgt  de  communicatie  tussen  alle  simulatiemodellen.  Het  RTI 
prototype  is  in  de  Verenigde  Staten  vrij  verkrijgbaar.  Of  de  RTI  voor  andere 
landen  beschikbaar  komt,  is  nog  onbekend"^, 

Het  huidige  prototype  was  oorspronkelijk  gebaseerd  op  CORBA  1.0  m.b.v.  de 
commerciele  software  development  tool  ORB IX™.  CORBA  (Common  Object 
Request  Broker  Architecture)  is  een  bestaande  standaard  om  objecten  te  distribue- 
ren  en  te  laten  communiceren  over  een  netwerk.  De  gebruiker  kan  deze  objecten 
raadplegen  zonder  te  weten  op  welk  computersysteem  het  object  zich  in  feite 
bevindt.  Aangezien  ORB IX  niet  voldoet  aan  de  stringente  eisen  van  de  HLA 
gemeenschap,  zal  ORBIX  in  de  volgende  versies  vervangen  worden  door  een  eigen 
implementatie.  Ook  is  er  voor  DMSO  een  prototype  RTI  ontwikkelt  die  niet  op 
CORBA  gebaseerd  is,  maar  op  0++.  De  RTI  gebruikt  CORBA’ s  IDL  (Interface 
Definition  Language)  als  Application  Programming  Interface  (API)  naar  de  fede¬ 
rate.  De  volgende  RTI  versie  zal  een  C+4-  API  bevatten. 


4 


Via  bilaterale  overeenkomsten  (FMS,  DEA,  MOU)  kunnen  NATO-partners  een 
RTI-versie  venverven. 
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Een  aantal  protofederations  die  elk  een  gebruikersgroep  vertegenwoordigen  heb- 
ben  met  de  RTI  geexperimenteerd: 

Warfighting  (Platform)  Federation: 

Real-time  man-in-the-loop  simulatie  op  platform  niveau  voor  het  trainen  van 
platform-  en  staf  personeel.  Deze  protofederation  vertegenwoordigt  een  groot  deel 
van  de  DIS-gemeenschap. 

Aggregate  Federation: 

Aggregate-level  simulatie  op  peletonsniveau  voor  het  trainen  van  stafpersoneel. 
Vertegenwoordigt  de  ALSP  (Aggregate  Level  Simulation  Protocol)  gemeenschap. 
Denk  bijvoorbeeld  aan  wargames  en  event-driven  simulatie. 

Analysis  Federation: 

Constructieve  simulatie  (computer  generates  forces  zoals  b.v.  ModSAF)  en  scena¬ 
rio  management  tools  voor  analyse  doeleinden. 

Engineering  Federation: 

Ontwerp,  test  en  evaluatie  van  vliegtuig  subsystemen  gerelateerd  aan  EOV  en 
counter-measures.  Dit  gebaseerd  op  de  HLA-omzetting  van  eerdere  gedetailleerde, 
high-fidelity  DIS-federates, 

Joint  Training  Federation  Prototype 

Hierbij  werden  bestaande  ALSP  en  DIS-federates  samengevoegd  tot  een  federa¬ 
tion.  Er  werden  geen  problemen  met  de  causaliteit  geconstateerd.  Dit  vanwege  de 
betrouwbare  en  gegarandeerde  aflevering  van  informatie. 

Alle  protofederations  zijn  tot  de  conclusie  gekomen  dat  de  functionaliteit  van  de 
RTI  voldoet  aan  hun  specifieke  eisen.  Ze  zijn  het  er  ook  over  eens  dat  de  perform¬ 
ance  van  de  RTI  ver  beneden  peil  ligt  met  latencies  van  1200  msec,  soms  zelfs 
hoger.  Dit  wordt  ten  dele  veroorzaakt  door  de  wijze  van  connection-oriented 
communicatie:  er  moet  gewacht  worden  op  een  acknowledgement  van  de  andere 
federate(s)  voordat  de  “update”  gerealiseerd  is.  Vreemd  genoeg  blijkt  de  commu¬ 
nicatie  niet  gelijkelijk  over  de  tijd  gedistribueerd  te  zijn,  maar  is  er  sprake  van 
“blokvorming”  in  de  communicatie.  Gegeven  de  eisen  van  betrouwbare  communi¬ 
catie,  treden  hierdoor  pieken  op  in  de  netwerkmedia  bezetting  en  de  afhandeling 
van  pakketten. 

De  huidige  versie  van  HLA/RTI  werd  hierom  tijdens  de  DIS-transition  workshop 
vergeleken  met  een  “Formule  1  wagen  op  stenen  wielen”. 

Een  ander  opvallend  gegeven  is  dat  het  langzaamste  systeem  in  een  federation  de 
bottleneck  vormt.  Dit  omdat  de  RTI  voortgang  opgehouden  wordt  totdat  dit  sys¬ 
teem  de  informatieontvangst  bevestigd  heeft ! 
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Vooral  de  Platform  Federation  toont  zich  hier  bezorgd  over.  De  RTI  bouwers 
beweren  dat  er  in  dit  prototype  alleen  naar  functionaliteit  is  gekeken  en  nog  hele- 
maal  niet  naar  performance.  Het  blijft  voorlopig  onzeker  of  de  RTI-performance  in 
de  toekomst  goed  genoeg  zal  worden  voor  real-time  applicaties  die  een  lage  laten¬ 
cy  vereisen  zoals  ‘fast  movers’  en  ‘close  combat’  (met  name  vliegtuig  en  missile 
simulaties). 

Nieuwe  concepten  in  de  RTI,  als  object  en  attribute  “hand-over”  blijken,  soms  tot 
verbazing  van  de  proto-federation  testers,  functioneel  goed  te  werken. 

3.4.2  Interface  Specification 

De  Interface  Specification  is  een  formele,  functionele  beschrijving  van  het  inter¬ 
face  tussen  enerzijds  de  HLA-applicatie  (b.v.  een  tank  simulator)  en  anderzijds  de 
RTI. 

De  Interface  Specification  biedt  functies  voor  de  reeds  eerder  vermelde  vijf  RTI 
Services: 

1 .  Federation  Management 

2.  Declaration  Management 

3.  Object  Management 

4.  Ownership  Management 

5.  Time  Management 

De  protofederations  hebben  gemeld  tevreden  te  zijn  met  de  geboden  Interface 
Specification  functionaliteit.  Vandaar  dat  het  interface  in  de  toekomst  waarschijn- 
lijk  vrij  stabiel  zal  blijven.  Het  interface  is  van  beide  kanten  benaderbaar.  D.w.z. 
dat  de  federate  services  kan  aanroepen  die  de  RTI  levert,  maar  ook  dat  de  RTI 
services  aanroept  die  de  federate  moet  leveren!  Bijvoorbeeld  bij  binnenkomst  van 
een  up-to-date  attribute  zal  de  RTI  een  federate-defined  function  aanroepen  die  de 
attribute  afhandelt. 

3.4.3  HLARules 

Dit  is  een  set  van  technische  principes  (de  “Ten  Commandments”  van  HLA) 
waaraan  HLA  deelnemers  zich  moeten  houden  om  HLA-compatible  te  zijn. 

Federation  Rules: 

1.  Hike  federation  moet  een  Federation  Object  Model  (FOM)  hebben  (de  FOM 
wordt  vastgelegd  conform  de  gestandaardiseerde  formaten  in  de  Object  Model 
Templates  (OMT)). 

2.  Alle  object  informatie  (status,  ownership)  bevindt  zich  in  de  federate,  niet  in  de 
Run-Time  Infrastructure  (de  federate  is  daarmee  verantwoordelijk  voor  de  ob¬ 
ject  presentatie). 
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3.  Informatieuitwisseling  (attributes  of  interactions)  tussen  de  in  de  FOM  gespeci- 
ficeerde  objecten  loopt  uitsluitend  via  de  Run-Time  Infrastructure. 

4.  Federates  interacteren  met  de  Run-Time  Infrastructure  conform  de  HLA  Inter¬ 
face  Specification. 

5.  Slechts  een  federate  kan  op  enig  tijdstip  eigenaar  zijn  van  een  attribute  van  een 
instantie  van  een  object.  Het  ‘ownership’  kan  wel  overgedragen  worden  aan  een 
andere  federate. 

Federate  Rules: 

1.  Hike  federate  moet  een  Simulation  Object  Model  (SOM)  hebben  conform  de 
gestandaardiseerde  formaten  in  de  Object  Model  Templates  (OMT). 

2.  Federates  moeten  in  staat  zijn  attributen  van  objecten  te  publiceren  of  reflecte- 
ren  zoals  in  hun  SOM  beschreven  staat.  Dit  geldt  ook  voor  interactions. 

3.  Federates  moeten  in  staat  zijn  attributen  van  objecten  te  beheren  (d.w.z.  eige¬ 
naar  zijn)  en  ‘ownership’  over  te  dragen  of  over  te  nemen. 

4.  Federates  moeten  in  staat  zijn  drempel  waarden  (thresholds)  te  wijzigen  die 
bepalen  wanneer  attributen  ge-update  moeten  worden. 

5.  Federates  moeten  in  staat  zijn  een  lokale  klok  bij  te  houden  om  conform  ten 
minste  een  time  management  service  aan  de  federation  deel  te  nemen. 

3.4.4  Object  Model  Templates 

De  Object  Model  Templates  zijn  gestandaardiseerde  formaten  die  gebruikt  moeten 
worden  om  de  functionaliteit  van  simulatie  modellen  vast  te  leggen  en  de  interactie 
tussen  deze  modellen.  Op  deze  manier  wordt  voor  de  oefening  vastgelegd  wat  de 
'capabilities'  van  alle  simulatie  modellen  is.  Tijdens  de  oefening  mag  niet  worden 
afgeweken  van  deze  specificaties. 

We  onderscheiden  de  volgende  tabellen: 

•  Class  Structure  Table: 

Specificatie  van  object  klasse  hierarchic  (class-subclass  relaties).  B.v.  Tank  be- 
hoort  tot  de  klasse  LandVehicle  en  LandVehicle  behoort  tot  de  klasse  Platform. 

•  Component  Structure  Table: 

Specificatie  van  object  componenten  hierarchic  (part-whole  relaties).  B.v.  Tank 
bestaat  uit  de  componenten  WeaponSystem,  Radar  etc. 

•  Association  Table: 

Specificatie  van  verdere  relaties  tussen  objecten  die  uitwisseling  van  attribuut- 
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waarden  mogelijk  maken.  Bijv.  Radar  is  geinteresseerd  in  positie-attribute  van 
Tanks. 

•  Object  Interaction  Table: 

Specificatie  van  berichten  verkeer  (interactions)  tussen  objecten.  Bijv.  Tank 
vuurt  en  stuurt  de  corresponderende  interaction  naar  de  andere  Tanks. 

•  Attribute  Table: 

Specificatie  van  alle  attributen  en  interactions  wat  betreft  data  type,  units,  re- 
solutie,  nauwkeurigheid  etc.,  Bijv.  Tank  heeft  een  gewicht-attribute  van  het  ty¬ 
pe  double,  kilogram  etc. 

•  Data  Dictionary: 

Alfabetische  lijst  van  alle  classes,  attributes,  interactions,  associations  met  tek- 
stuele  uitleg  en  structuur. 


3.5  Beveiliging  en  HLA 

Door  Trusted  Information  Systems  Inc.  (TIS)  wordt  een  security  architectuur 
ontwikkeld  voor  HLA,  De  beveiligingsproblematiek  wordt  in  verschillende  stap- 
pen  aangepakt.  Op  korte  termijn  is  alleen  een  federation  op  basis  van  “System 
High”  mogelijk.  “System  High”  is  een  omgeving  waarin  alle  gebruikers/ 
deelnemers  minimaal  tot  het  hoogste  te  gebruiken  beveiligingsniveau  (bijv.  US 
Secret)  gecleared  zijn. 

Op  middellange  termijn  (ca.  vijf  jaar!)  is  scheiding  tussen  twee  beveiligings- 
niveaus,  bijv.  Geheim  en  Confidentieel,  mogelijk  door  ieder  beveiligingsniveau  als 
een  aparte  netwerk  op  te  zetten,  waarbij  een  “guard”  (op  federate-niveau)  optreedt 
als  veilige  gateway-koppeling  tussen  beide  netwerken.  In  TCSEC-termen  dient  de 
guard  minimaal  te  voldoen  aan  B3-normen,  hetgeen  de  ontwikkel-  en  evaluatietijd 
sterk  nadelig  beinvloedt.  Vervolgens  kan  accredidatie  in  de  werkomgeving  plaats- 
vinden. 

Pas  op  lange  termijn  wordt  gedacht  aan  een  multi-level  beveiligde  oplossing. 

Bij  de  middellange  termijn-oplossing,  de  guard,  is  sprake  van  drie  FOM’s:  twee 
FOM’s  voor  de  beschrijving  van  beide  rubriceringsomgevingen  en  een  gecombi- 
neerde  FOM  die  de  toegestane  interactie  (“sanitation  rules”)  en  uit  te  wisselen 
objecten  tussen  beide  omgevingen  vastlegt. 

Voor  iedere  federation  is  sprake  van  een  enkele  beveiligings-policy,  een  gezamen- 
lijk  bezit  en  gedeelde  verantwoordelijkheid  voor  de  toegestane  uit  te  wisselen 
attributen  van  objecten  die  tussen  de  beveiligingsniveaus  ge”shared”  mogen  wor- 
den. 
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Voor  de  after-action  reviews  zal  dit  zeker  problemen  geven,  omdat  b.v.  een  vlieg- 
tuig-federate  in  de  confidentiele  omgeving  b.v.  een  object-id  109  heeft  en,  indien 
dit  object  zichtbaar  mag  zijn  in  de  geheime  omgeving,  daar  een  volkomen  ander 
object-id  krijgt.  Dit  omdat  de  FOM’s  geen  inzicht  hebben  in  de  “exteme”  relaties 
achter  de  RTI.  Loggings  zijn  dus  niet  meer  samen  te  voegen,  tenzij  alle  attributen 
in  de  “share  FOM”  worden  geplaatst  en  de  logger  op  “hoog  beveiligingsniveau” 
zich  daar  op  abonneert. 

Omdat  de  evaluatie  van  een  guard  zeer  problematisch  is,  probeert  TIS  de  guard 
zodanig  te  ontwerpen  en  te  ontwikkelen,  dat  deze  schaalbaar  en  veilig  configureer- 
baar  is.  Zaken  die  bestudeerd  worden  zijn:  schaalbaarheid,  beveiligingsimplicaties 
van  filtering,  performance,  (on)gewenste  signaleringskanalen,  deductie  van  ver- 
trouwelijke  gegevens  uit  vrijgegeven  informatie  en  spoofing. 

Op  dit  gebied  dienen  nog  vele  concepten  uitgediept  te  worden,  zeker  als  multi- 
nationale  interoperabiliteit  aan  de  orde  komt. 
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4.  STOW 


Binnen  het  Synthetic  Theatre  Of  War  (STOW)  wordt  gewerkt  aan  grootschalige 
simulaties  met  meer  dan  10.000  entiteiten,  gebaseerd  op  de  HLA-technologie.  De 
complexiteit  van  deze  hoeveelheid  entiteiten  vergen  een  enorme  netwerkcapaciteit 
indien  voortgebouwd  zou  worden  op  de  DIS-wijze  van  connecties  tussen  federates. 
Daarnaast  kunnen  de  simulatoren  de  grote  hoeveelheden  data  niet  tijdig  verwerken 
of  is  een  (onnodig)  grote  verwerkingscapaciteit  nodig.  Als  voorbeeld  werd  gesteld 
dat  CPU’s  100--150  microseconden  nodig  hebben  om  een  informatiepakket  te 
verwerken. 

Gestudeerd  wordt  op  technieken  om  de  benodigde  hoeveelheid  data-transporten  te 
minimaliseren.  De  RTI-aanpak,  waarbij  een  federate  zich  “abonneert”  op  object 
attributen  helpt  daarbij.  Met  name  als  de  object  instantiaties  zich  niet  of  langzaam 
bewegen  (b.v.  uitgestegen  entiteiten;  logistieke  acties  als  laden  of  lossen), 

Gekeken  wordt  naar  een  optimale  wijze  van  filteren  van  informatie  in  de  RTI. 
Hierbij  kan  op  verschillende  plaatsen  gefilterd  worden:  door  de  informatiezender, 
door  het  netwerk  of  door  de  ontvanger.  Hierbij  is  het  van  belang  de  “routing 
spaces”  te  onderkennen:  welke  informatie  is  belangrijk  en  hoe  moet  deze  gerepre- 
senteerd  zijn  (bijv.  km  versus  mijlen). 

Bij  zender  gedreven  filtering,  meldt  een  federate  aan  een  andere  RTI  de  interesse 
in  de  gegevens  binnen  een  bepaald  gebied  (region),  bijvoorbeeld  “alles  in  de 
zichtomgeving”.  De  RTI  werkt  de  object  attributen  bij  en  selecteert  vervolgens  de 
informatie  die  de  “abonnee”  nodig  heeft  en  verstuurt  die. 

Ingeval  van  receiver  based  filtering,  bouwt  de  ontvanger  een  boom  op  met  meerde- 
re  “regions  of  interest”,  die  steeds  fijner  opgedeeld  zijn.  Via  het  netwerk  wordt 
vervolgens  een  optimale  verbindingsboom  onderhouden,  waardoor  de  hoeveelheid 
gegevens  via  het  netwerk  binnen  redelijke  grenzen  blijft. 

Uitgaande  van  gegevens  van  een  eerdere  STOW  exercitie,  blijkt  zender  based 
filtering  met  een  2-5  km  grid  circa  30%  reductie  in  netwerkverkeer  op  te  leveren. 
Hierbij  is  100%  netwerkverkeer  gelijk  aan  het  versturen  van  alle  update  informatie 
naar  iedere  federate  (broadcast), 

Bij  receiver  based  filtering  kan  een  verdere  reductie  bereikt  worden,  afhankelijk 
van  de  “diepte”  of  de  gedetailleerdheid  van  de  “interest”-omgeving.  Bij  een  diepte 
3  wordt  een  40%  reductie  bereikt,  bij  een  diepte  5  wordt  een'halvering  van  het 
netwerkverkeer  bereikt.  Het  theoretisch  haalbare  is  een  reductie  met  55%. 
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5.  SEDRIS 


In  September  ‘94,  mede  voortkomend  uit  de  werkgroep  “Simulated  Environment” 
van  de  DIS  Workshop,  is  een  project  gestart  met  als  doel  om  ook  standaardisatie  te 
bereiken  in  de  representatie  van  de  synthetische/virtuele  omgeving  waarin  de 
gedistribueerde  simulatoren  functioneren  (terrein,  atmosfeer,  water). 

Voor  de  bevordering  van  de  interoperabiliteit  (en  een  ‘fair  fight’)  tussen  de  ver- 
schillende  simulaties,  is  niet  alleen  standaardisatie  noodzakelijk  in  het  berichten- 
verkeer  tussen  de  simulatoren  (DIS/HLA),  maar  moeten  ook  de  interne  data  bases 
die  de  fysische  aspecten  van  de  werkelijke  wereld  (omgeving)  specificeren,  zoveel 
als  mogelijk,  onderling  consistent,  compleet  en  ondubbelzinnig  zijn.  Uiteraard 
geldt  dat  voor  de  (terrein)  data  bases  voor  de  zichtsystemen  in  simulatoren,  maar 
o.a.  ook  voor  andere  sensoren  (warmtebeeld,  radar,  laser)  en  de  data  bases  waar- 
mee  Computer  Generated  Forces  (CGF)  programma’s  werken. 

Eerdere  pogingen  tot  een  open  standaardisatie  (bijv.  Project  2851,  SIF,  SIF++) 
hadden,  althans  vanuit  het  gezichtspunt  van  interoperabiliteit,  niet  het  gewenste 
resultaat.  Het  project  “Synthetic  Environment  Data  Representation  Interchange 
Specification”  (SEDRIS)  biedt  meer  perspectief. 

De  doelstellingen  van  SEDRIS  zijn: 

•  het  vastleggen  van  de  complete  set  van  data-elementen  en  geassocieerde  rela- 
ties  die  nodig  zijn  om  de  omgeving  volledig  te  representeren; 

•  volledige  ondersteuning  van  de  diverse  typen  simulaties,  zoals  CGF,  bemande 
en  visuele  systemen,  sensorsimulaties; 

•  een  standaard  data  uitwisselingsformaat  en  -mechanisme  te  verschaffen,  welke 
zo  compleet  als  mogelijk  is,  zonder  verlies  van  detail-data. 

De  aanpak  van  het  projectteam  (een  negental  individuele  deskundigen,  met  mini¬ 
male  commerciele  bindingen)  is,  om  eerst  een  goed  en  volledig  data-model  te 
ontwikkelen  en  daarop  gebaseerd,  een  compleet  data  interchange  format.  Essen- 
tieel  is  daarbij  de  tussentijdse  terugkoppeling  van  de  (data  base  tools)-industrie 
door  middel  van  gecontracteerde  prototyping  met  het  data-model  en  met  ‘Read-  en 
Write- APIs’. 

Een  en  ander  zou  in  1998  tot  een  eindresultaat  moeten  leiden. 
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6.  Conclusies 


•  Samen  met  de  Annex  is  de  IEEE  1278.1:  Standard  for  Distributed  Interactive 
Simulation  -  Application  Protocols  een  tamelijk  complete  set  van  protocollen 
om  (real-time  voor  menselijke  perceptie)  de  gebeurtenissen  in  een  synthe- 
tisch/virtueel  gevechtsveld  te  beschrijven  en  de  interacties  tussen  gesimuleerde 
wapenplatformen  te  specificeren.  Op  een  aantal  protocollen  dient  de  kennis  en 
ervaring  nog  verdiept  te  worden. 

•  HLA  is  een  hot  topic.  Het  moet  de  opvolger  worden  van  bestaande  standaarden 
zoals  DIS  en  ALSP.  Gebruikers  uit  de  verschillende  domeinen  zijn  tevreden 
over  de  HLA-functionaliteit  maar  ontevreden  over  de  performance  van  de  eer- 
ste  implementatie. 

•  De  overgang  van  DIS  naar  HLA  zal  een  groeipad  zijn. 

Aangezien  de  toekomst  van  gedistribueerde  simulatie  nog  niet  duidelijk  is,  is 
het  verstandig  nieuwe  applicaties  te  abstraheren  van  deze  turbulentie.  Dit  is 
mogelijk  door  een  tussenlaag  (ook  wel  ‘middleware’  of  ‘abstraction  layer’  ge- 
noemd)  te  gebruiken  die  voor  de  eerstkomende  jaren  een  DIS-compliant  inter¬ 
face  biedt  en  later  ook  een  HLA-compliant  interface. 

•  Bij  het  huidige  ontwerp  van  de  RTI  is  minimaal  aandacht  besteed  aan  de  on- 
derliggende  netwerklaag,  Er  zijn  hiervoor  geen  interface  specificaties  opge- 
steld.  Toch  zou  de  RTI-communicatie  via  vele  verschillende  fysieke  media/- 
communicatielagen  moeten  kunnen  lopen  (b.v.  geheugenkoppeling,  ATM, 
ISDN,  Ethernet). 

•  Los  van  de  technische  pro’s  en  contra’s  van  HLA  versus  DIS  zal  een  van  de 
repercussies  van  het  DoD-mandaat  zijn,  dat  op  termijn  de  industriele  onder- 
steuning  van  de  DIS  IEEE  1278  standaarden  zal  gaan  wegebben  door  het  weg- 
vallen  van  een  belangrijke  markt  in  de  toepassing  ervan.  Voor 
(simulatie)systemen  met  een  gefixeerde  omvang  (zonder  geplande  groeipotenti- 
eel  na  in  gebruikname)  behoeft  dit  minder  een  probleem  te  zijn;  met  (al  dan  niet 
geplande)  groeipotentieel  wel. 

•  Naast  de  protocol-  en  architectuurstandaarden  (DIS/HLA)  ten  behoeve  van 
interoperabiliteit  van  simulaties,  zijn  standaarden  voor  de  beschrijving  en  re- 
presentatie  van  de  synthetische  omgeving  van  belang.  In  dat  verband  biedt  het 
SEDRIS-initiatief  meer  perspectief  dan  eerdere  (te  beperkte)  pogingen.  Ook  op 
dit  gebied  ware  de  kennis  en  ervaring  te  verdiepen. 
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7.  Afkortingen 


ALSP 

AMG 

API 

ARPA 

ATM 

CCTT 

CORBA 

DARPA 

DIS 

DMSO 

DoD 

FAQ 

FOM 

FRED 

HLA 

IDL 

IEEE 

IFF 

IP 

ISDN 

1ST 

M&S 

ModSAF 

MS 

OMT 

PDU 

PnP-FOM 

RFC 

RID 

RITN 

RTI 

SAC 

SEDRIS 

SIMNET 

SOM 

STOW 

STGVIP 

TCP 

TCSEC 

UDP 

VV&A 


Aggregate  Level  Simulation  Protocol 
Architecture  Management  Group  (van  HLA) 

Application  Programming  Interface 
zie  DARPA 

Asynchronous  Transfer  Mode 
Close  Combat  Tactical  Trainer 
Common  Object  Request  Broker  Architecture 
Defense  Advanced  Research  Projects  Agency  (US) 

Distributed  Interactive  Simulation 
Defense  Modeling  and  Simulation  Office  (US) 

Department  of  Defense  (US) 

Frequently  Asked  Questions 

Federation  Object  Model 

Federation  Required  Execution  Details 

High  Level  Architecture 

Interface  Definition  Language 

Institute  of  Electrical  and  Electronics  Engineers 

Identification  Friend  or  Foo 

Internet  Protocol  (RFC  791) 

Integrated  Services  Digital  Network 

Institute  for  Simulation  and  Training,  University  of  Central  Florida 
Modeling  and  Simulation 
Modular  Semi  Automated  Forces 
Microsoft 

Object  Model  Template 
Protocol  Data  Unit 
Plug-and-Play  FOM 

Request  for  Comment  (Internet  standaard) 

RTI  Initialization  Data 

Real-time  Information  Transfer  and  Networking 
Run  Time  Infrastructure 
Standards  Activity  Committee 

Synthetic  Environment  Data  Representation  Interchange  Specification 

SIMulator  NETwork 

Simulation  Object  Model 

Synthetic  Theatre  of  War 

Special  Task  Group:  Vision  Implementation  Plan 

Transmission  Control  Protocol  (RFC  793) 

Trusted  Computer  Security  Evaluation  Criteria 
User  Datagram  Protocol  (RFC  768) 

Verification,  Validation  &  Accreditation 
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Defense  for  Acquisition  and  Technology 
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THE  UNDER  SECRETARY  OF  DEFENSE 
3010  DEFENSE  PENTAGON 
WASHINGTON.  D.C.  20301-3010 

SEP  1  0  1996 

ACQUISITION  AND 
TECHNOLOGY 

MEMORANDUM  FOR:  SECRETARIES  OF  THE  MILITARY  DEPARTMENTS 

CHAIRMAN  OF  THE  JOINT  CHIEFS  OF  STAFF 
UNDER  SECRETARIES  OF  DEFENSE 
ASSISTANT  SECRETARIES  OF  DEFENSE 
GENERAL  COUNCIL  OF  THE  DEPARTMENT  OF  DEFENSE 
INSPECTOR  GENERAL  OF  THE  DEPARTMENT  OF  DEFENSE 
DIRECTOR,  OPERATIONAL  TEST  AND  EVALUATION 
ASSISTANTS  TO  THE  SECRETARY  OF  DEFENSE 
DIRECTOR  OF  ADMINISTRATION  AND  MANAGEMENT 
DIRECTORS  OF  THE  DEFENSE  AGENCIES 

SUBJECT:  DoD  High  Level  Architecture  (HLA)  for  Simulations 

References:  (a)  DoD  Directive  5000.59,  “DoD  Modeling  and  Simulation  (M&S) 
Management,”  January  4,  1994 

(b)  DoD  5000. 59-P,  “DoD  Modeling  and  Simulation  Master  Plan 
(MSMP),”  October  1995 

Under  the  authority  of  reference  (a),  and  as  prescribed  by  reference  (b),  I  designate  the 
High  Level  Architecture  as  the  standard  technical  architecture  for  all  DoD  simulations. 

The  baseline  HLA  is  defined  by  three  inter-related  elements:  HLA  Rules  Version  1.0 
(v.  1 .0),  HLA  Interface  Specification  v.  1 .0,  and  HLA  Object  Model  Template  v.  1 .0.  The  evolu¬ 
tion  of  the  HLA  will  be  managed  by  the  DoD  Executive  Council  for  Modeling  and  Simulation 
(EXCIMS)  through  its  Architecture  Management  Group  (AMG).  This  structure  provides  a 
means  for  the  DoD  Components  to  identify  and  address  any  emergent  issues  in  subsequent 
refinements  to  the  HLA.  Compliance  with  the  HLA  does  not  mandate  the  use  of  any  particular 
implementation  of  supporting  software  such  as  the  Runtime  Infrastructure. 

DoD  Components  shall  review  all  of  their  simulation  projects  and  programs  by  the  second 
quarter  fiscal  year  (FY)  1997  in  order  to  establish  plans  for  near-term  compliance  with  the  HLA. 
TTie  Department  shall  cease  further  development  or  modification  of  all  simulations  which  have 
not  achieved,  or  are  not  in  the  process  of  achieving,  HLA-compliance  by  the  first  day  of  FY 
1999,  and  shall  retire  any  non-compliant  simulations  by  the  first  day  of  FY  2001.  EXCIMS  is  to 
monitor  progress  and  advise  me  if  any  emergent  events  affect  their  viability. 

To  monitor  compliance  with  the  HLA,  the  DoD  Components  shall  submit  an  initial  report 
to  the  Defense  Modeling  and  Simulation  Office  (DMSO)  by  June  30,  1997,  which  summarizes 
their  HLA-compliance  intentions  for  each  simulation  the  Component  owns  or  sponsors,  orga¬ 
nized  into  three  categories: 

•  HLA-compliance  actions  initiated  immediately 

•  HLA-compliance  actions  initiated  at  a  specified  future  date 

•  no  HLA  compliance  planned  (thus  requiring  eventual  retirement  or  a  waiver) 
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The  DoD  Components  shall  submit  periodic  updates  to  these  initial  reports  as  required  to 
ensure  their  accuracy  and  completeness.  DMSO  shall  establish  a  mechanism  to  provide  for 
formal  certification  of  compliance  and  shall  provide  me  with  periodic  reports  on  the 
Department’s  progress  towards  compliance  with  the  HLA. 

If  a  Component  believes  it  is  impractical  for  a  simulation  to  comply  with  the  HLA,  or  that 
HLA-compliance  caimot  be  achieved  in  a  timely  maimer,  it  may  submit  a  waiver  request  to  the 
Director  of  Defense  Research  and  Engineering,  the  Chair  of  the  EXCIMS.  In  consultation  with 
the  EXCIMS  and  its  Training,  Analysis,  and  Acquisition  Councils,  I  will  then  decide  if  an  excep¬ 
tion  to  the  HLA-compliance  requirement  is  warranted,  and  if  so,  the  form  of  that  exception. 

This  mandate  for  HLA-compliance  supersedes  all  previous  requirements  for  DoD  simula¬ 
tions  to  comply  with  other  simulation  standards  such  as  Distributed  interactive  Simulation  or 
Aggregate-Level  Simulation  Protocol.  It  is  expected  that  new  industry  standards  to  support  the 
HLA  will  emerge.  In  consultation  with  the  EXCIMS  and  its  AMG,  I  will  evaluate  the  suitability 
of  such  standards  for  the  Department  as  they  are  established. 

The  DoD  point  of  contact  for  the  HLA  is  the  Defense  Modeling  and  Simulation  Office  at 
(703)  998-0660  or  hla@dmso.mil.  The  HLA  documents  are  available  at  http://www.dmso.mil/. 

Paul  G.  Kaminski 
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Bijiage  B  DIS++/HLA  Frequently  Asked  Questions 


DIS++  /  HLA  Frequently  Asked  Questions 
Last  updated  April  22, 1996 

The  following  list  of  questions  and  answers  is  provided  in  response  to  inquiries  from  the  14th  DIS 

Workshop. 

Responses  to  the  questions  have  been  prepared  through  the  coordinated  efforts  of  the  Workshop 

Steering  Committee  and  the  Defense  Modeling  and  Simulation  Office  (DMSO). 

This  list  of  questions  and  answers  is  intended  to  serve  the  following  purposes: 

a.  Provide  a  consistent  baseline  of  information  regarding  the  current  and  future  direction  of  Work¬ 
shop  and  DMSO  activities. 

b.  Build  a  common  understanding  and  support  within  the  M&S  community  for  the  Workshop 
purpose  and  objectives. 

c.  Provide  the  best  information  at  the  time  of  publication.  New  questions  and  revisions  to  answers 
may  occur  as  results  of  on  going  activities  reach  completion. 

Comments  regarding  this  list  may  be  provided  through  the  DIS-STD-STGVIP  reflector.  See  answer 

to  question  43. 


HLA  FAQ 

1.  What  will  be  included  in  the  baseline  definition  of  HLA?  When  will  it  be  available? 

ANSWER:  The  baseline  definition  of  the  HLA  is  due  to  be  released  in  August  1996,  at  the  end  of  the 
prototyping  period.  It  will  include  a  capstone  description  of  the  HLA  (a  top-level  summa¬ 
ry  of  the  basic  architecture  structure),  the  HLA  rules  (underlying  technical  principles),  the 
HLA  Interface  Specification  between  the  RTI  and  the  federates,  the  HLA  Object  Model 
Template,  and  an  HLA  Glossary,  Accompanying  the  release  of  the  baseline  definition 
will  be  an  initial  set  of  supporting  documentation,  which  will  include  descriptions  of  the 
HLA  federation  design  and  execution  process,  common  test  procedures,  a  security  archi¬ 
tecture  for  HLA,  time  management  functions  under  the  HLA.  declaration  management 
functions,  use  cases  based  on  the  AMG  prototyping  experiences,  and  other  technical  do¬ 
cuments. 

During  the  prototyping  process,  the  AMG  has  developed  prototype  software  for  the  HLA 
Runtime  Infrastructure  (RTI),  the  distributed  operating  system  for  an  HLA  federation. 

This  has  been  produced  under  a  spiral  development  scheme,  with  sequential  releases  of 
versions  of  the  RTI  software  to  the  AMG  members  for  testing  in  prototype  federations 
(“proto-federations”),  with  feedback  to  the  RTI  developers  folded  into  the  next  iteration 
and  subsequent  release.  RTI  version  0.3  is  due  to  be  released  on  30  April,  and  version 
0.4  on  1 5  July. 

2.  What  is  a  federation?  What  is  a  FOM?  What  is  FRED? 

ANSWER:  A  federation  under  the  High  Level  Architecture  (HLA)  for  modeling  and  simulation  is  a 
named  set  of  interacting  federates  (simulations,  C4I  system  interfaces,  data  collectors, 
etc.),  with  a  common  federation  object  model,  and  supporting  Runtime  Infrastructure 
software,  that  arc  used  as  a  whole  to  achieve  some  specific  objective. 
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A  Federation  Object  Model  (FOM)  is  an  identification  of  the  essential  classes  of  objects, 
their  attributes,  associations,  and  interactions  that  are  supported  by  a  federation.  The 
FOM  is  like  a  “contract”  between  the  federates,  describing  the  type  of  data  they  agree  to 
share  through  the  RTI  during  a  federation  execution.  This  data  is  specified  in  a  manner 
prescribed  by  the  Object  Model  Template,  a  tabular  format  which  includes  an  object  class 
structure,  interactions,  attributes,  and  a  data  dictionary. 

As  shown  in  the  Federation  Development  and  Execution  Process  diagram  on  the  DMSO 
Web  pages  (http://www.dmso.mil),  the  Federation  Required  Execution  Details  (FRED) 
are  used  in  the  preparation  of  a  Federation  Execution.  FRED  data  is  drawn  from 

*  the  FOM 

*  federation  common  components 

*  scenario  information 

*  management  requirements 

*  execution  environment 

FRED  data  is  recorded  in  a  specific  format  to  be  defined  by  the  federation  developers. 
This  data  will  be  used  to  supply  information  to  the  RTI  Initialization  Data  (RID),  to  the 
Federation  Test  process,  and  to  the  federation  execution.  Any  of  the  customers  of  FRED 
data  may  further  reduce  the  data  to  a  form  more  suitable  for  efficient  runtime  execution. 

3.  Will  HLA  be  more  than  a  software  interface  architecture? 

ANSWER:  The  HLA  is  more  than  an  interface  specification.  It  also  prescribes  an  object  model 

template  for  documenting  the  objects,  attributes,  and  interactions  which  will  be  exchan¬ 
ged  during  a  federation  runtime  execution,  and  a  set  of  HLA  rules  or  underlying  technical 
principles  which  prescribe  certain  functionality  for  both  federates  (simulations)  and  fede¬ 
rations.  In  addition,  the  HLA  specifies  a  Runtime  Infrastructure  (RTI),  in  effect  a  distri¬ 
buted  operating  system,  which  provides,  through  common  software,  certain  services 
which  formerly  were  the  responsibility  of  the  individual  simulations. 

4.  Is  HLA  more  than  an  ALSP  upgrade? 

ANSWER:  Yes.  Both  ALSP  and  DIS  have  been  successful  in  the  application  areas  for  which  they 
were  designed.  The  HLA  is  an  attempt  to  capture  the  best  ideas  derived  from  experience 
with  both  ALSP  and  DIS,  but  with  an  eye  to  applying  M&S  to  a  broader  set  of  applica¬ 
tions,  with  increased  potential  for  interoperability  of  different  simulations  and  reuse  of 
simulation  components.  The  HLA  is  being  designed  to  support  a  wider  range  of  DoD 
M&S  applications  with  more  functionality  than  either  ALSP  or  DIS  alone. 

5.  What  does  HLA  add  to  current  ADS/DIS  capabilities?  Have  the  additional  capabilities 
been  demonstrated? 

ANSWER;  Currently,  DIS  is  designed  to  support  realtime,  platform  level  simulations.  HLA  provides 
an  added  set  of  services  to  apply  to  a  broader  set  of  applications.  These  include  time  ma¬ 
nagement  services  (for  logical  time  simulations),  declaration  management  services  (for 
larger  scale  applications),  and  object  ownership  services  (for  added  functionality).  These 
are  all  services  designed  to  support  a  wider  range  of  users  than  currently  supported  by 
DIS  technology,  but  who  are  seen  as  eventual  users  of  future  DIS++  as  laid  out  in  the  DIS 
Vision.  The  additional  functionality  and  interoperability  provided  by  the  HLA  is  being 
demonstrated  through  a  series  of  prototype  efforts  under  the  direction  of  the  DoD  Archi¬ 
tecture  Management  Group  (AMG). 


6. 


When  will  a  design  document  and  functional  description  be  available  for  the  RTI? 


ANSWER;  A  top-level  functional  description  of  the  prototype  RTI  was  presented  by  members  of  the 
RTI  development  team  (from  Lincoln  Lab  and  Mitre)  at  the  14th  DIS  Workshop.  Copies 
of  the  papers  and  briefing  charts  are  available  on  the  DMSO  HLA  pages  on  the  World 
Wide  Web.  Beyond  the  prototype  stage,  the  basic  design  document  and  functional  des¬ 
cription  for  the  reference  implementation  of  the  RTI  (version  1.0)  is  expected  to  be  deve¬ 
loped  following  the  baseline  HLA  definition  release  in  August. 

7.  Is  the  RTI  open?  How  do  I  get  a  copy  of  the  RTI?  When  will  it  be  available  outside  the 
proto-federations?  What  will  it  cost  to  purchase?  What  will  it  cost  to  run? 

ANSWER:  Prototype  RTI  software  is  being  developed  in  support  of  the  HLA  definition  process.  The 
current  RTI  prototype  is  being  used  with  a  range  of  DoD  simulations  in  a  set  of  prototype 
federations  (“proto-federations”)  directed  toward  verifying  and  refining  the  initial  HLA 
definition.  A  baseline  definition  of  the  HLA  will  be  released  in  August  1996,  based  on 
the  work  of  the  AMG.  This  baseline  will  be  augmented  by  a  set  of  supporting  documents 
(test  procedures,  security  architecture,  development  process  description)  which  will  be 
released  by  October.  HLA  supporting  software,  including  the  RTI,  developed  during  the 
prototyping  period  will  be  updated  to  conform  to  the  baseline  HLA  definition  and  made 
available  for  more  general  distribution  and  use  as  soon  as  possible  following  the  August 
baseline.  Plans  are  now  being  made  for  this  release,  and  once  they  are  in  place  we  will 
publish  them  through  the  AMG  and  the  DMSO  home  page.  It  is  envisioned  that  this  ver¬ 
sion  will  be  government-owned  freeware,  available  at  no  cost  for  use  in  adapting  and  de¬ 
veloping  new  HLA-compliant  simulations. 

8.  What  about  the  latency  in  the  RTI  (especially  CORBA)?  Can  it  support  real  time  simula¬ 
tion? 

ANSWER:  It  is  recognized  that  RTI  latency  and  throughput  are  critical  issues,  particularly  for  real¬ 
time  and  faster-than-real-time  simulations.  A  key  part  of  the  design  process  for  the  pro¬ 
totype  RTI  involves  assessing  the  performance  of  the  selected  CORBA  implementation 
with  respect  to  these  factors.  Three  of  the  prototype  federations  helping  to  refine  the 
HLA  include  federates  who  previously  used  DIS,  and  they  will  be  paying  close  attention 
to  latency.  Where  CORBA  performance  is  found  to  be  inadequate,  other  mechanisms  in¬ 
volving  the  direct  use  of  UDP  or  TCP/IP  protocols  are  being  employed.  The  prototype 
RTI  is  intended  to  provide  us  the  experience,  test  results,  and  insights  necessary  to  allow 
the  development  of  an  operational  RTI  which  meets  user  needs.  The  prototype  RTI  is  le¬ 
veraging  techniques  developed  under  the  ARPA  Synthetic  Theater  of  War  (STOW)  pro¬ 
gram,  and  represent  the  most  advanced  approaches  to  large-scale  distributed  simulation 
applications  demonstrated  to  date. 

9.  Will  the  RTI  require  an  executable  like  CORBA?  What  about  the  cost  of  CORBA?  What 
about  the  stability  of  the  CORBA  standard? 

ANSWER:  As  indicated  in  the  response  to  Question  8,  decisions  about  how  various  RTI  services  are 
implemented  arc  being  made  on  a  case-by-case  basis,  depending  on  the  measured  capabi¬ 
lities  of  the  current  CORBA  software  in  the  context  of  the  overall  RTI  design.  The  RTI 
development  team  has  adopted  a  commercial  software  development  tool  (ORBIX”^^)  to 
produce  the  initial  prototype  of  the  RTI  software.  It  presently  is  based  on  CORBA  I.O, 
with  some  custom  modifications  to  enable  multicasting.  This  choice  was  made  to  imple¬ 
ment  the  widest  range  of  RTI  services  as  quickly  as  possible.  It  is  felt  that  CORBA  2.0 
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will  remove  the  dependence  on  specific  vendors  and  will  have  the  necessary  stability  to  be 
used  in  RTI  version  1.0.  When  the  initial  prototype  implementation  is  completed  with 
RTI  version  0.4,  an  assessment  will  be  made  based  on  the  RTFs  then-current  configura¬ 
tion.  Possible  recommendations  include  further  development  based  on  the  initial  model, 
the  incorporation  of  some  other  CORBA  implementation  based  on  alternatives  then  avai¬ 
lable,  or  even  development  not  using  a  commercial  CORBA  product.  In  many  respects, 
this  will  represent  a  classic  "make  vs.  buy"  analysis.  It  is  too  early  to  project  the  outcome 
of  this  analysis,  much  less  to  speculate  on  the  cost  of  off-the-shelf  software  components  at 
that  time. 

10.  What  is  the  RTI  communications  layer?  Where  does  one  get  information  on  the  commu¬ 
nications  layer? 

ANSWER:  The  RTI  prototype  implementation  is  using  standard  protocols  such  as  UDP  or  TCP/IP, 
RSVP,  and  NTP.  A  "virtual  network"  layer  is  being  implemented  to  isolate  the  RTI  func¬ 
tions  as  much  as  possible  from  changes  in  the  underlying  communication  mechanisms 
(such  as  IP,  native  ATM,  or  shared  memory).  The  implementation  is  employing  a  number 
of  techniques  developed  under  ARPA's  Real-Time  Information  Transfer  and  Networking 
(RITN)  effort,  such  as  the  Consistency  Protocol,  to  maintain  overall  distributed  database 
consistency  without  demanding  reliable  delivery  of  each  simulation  state  update.  The  re¬ 
sults  of  this  effort  on  the  RTI  prototype  will  be  documented  and  should  be  available  by 
October. 

1 1.  Will  HLA  be  sufficiently  tested  before  transitioning  to  it? 

ANSWER:  The  HLA  is  being  tested  prior  to  the  formal  baseline  definition  through  a  series  of 
prototypes.  These  provide  a  variety  of  conditions  and  test  scenarios  which  address  a 
range  of  potential  DoD  Mc&S  applications.  The  AMG  is  developing  common  interface 
test  procedures,  which  will  be  benchmarked  against  the  experience  gained  through  the 
AMG  proto-federations.  In  all,  more  than  25  separate  simulations  and  simulators 
(“federates”)  are  being  adapted  or  built  to  participate  in  the  proto- federations.  This  will 
provide  an  initial  cross-section  of  experience  across  a  number  of  M&S  application  areas, 
from  training  to  analysis  to  engineering  models.  Performance  analysis  of  prototype  im¬ 
plementations  of  the  RTI  and  proto-federations  will  be  conducted  to  develop  necessary 
performance  specifications  for  future  infrastructure  (e.g.,  RTI)  development. 

12.  What  type  of  test  will  be  used  to  evaluate  the  proto-federations  and  the  RTI  prototype? 

ANSWER:  Performance  testing  will  take  place  in  different  proto-federations,  using  a  common 

performance  measurement  framework  and  a  common  interface  test  procedure.  Each  pro¬ 
to-federation  is  developing  its  own  test  plan  for  assessing  the  HLA  for  applicability  to 
their  applications.  Feedback  from  the  proto-federations  on  the  testing  procedures  will  be 
used  to  revise  the  test  procedures  as  a  supporting  document  to  the  HLA  baseline  defini¬ 
tion.  Emphasis  will  be  placed  on  learning  where  within  the  proto-federations  various  la¬ 
tencies  occur,  as  well  as  where  throughput  bottlenecks  occur.  This  information  will  be 
used  in  recording  "lessons  learned"  and  in  formulating  recommendations  for  subsequent 
RTI  development.  In  terms  of  the  RTI,  tests  will  focus  on  communications  efficiency  (in 
terms  of  minimizing  communications  overhead  and  communications  redundancy),  end-to- 
end  latency,  and  overall  throughput  (attribute  updates  per  second).  Where  attribute  up¬ 
date  filtering  is  employed,  it  is  desirable  that  the  RTI  deliver  all  the  relevant  updates  to 
the  subscribing  federates,  with  a  minimum  of  extraneous  or  irrelevant  information  that 
must  be  discarded  at  the  destination. 
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13.  Will  the  HLA  be  language  neutral?  Will  the  RTI?  Will  we  always  have  to  use  C++? 

ANSWER:  The  HLA  will  be  language  neutral,  since  it  is  an  architecture,  independent  of  implementa¬ 
tion  language.  In  terms  of  the  simulations  within  a  federation,  the  only  requirement  is 
that  they  be  described  in  terms  of  objects,  attributes,  and  interactions,  and  that  it  conform 
to  a  standard  (common)  API.  While  it  is  an  option  for  simulation  developers,  there  is  no 
intent  or  implication  that  the  simulations  must  be  implemented  in  an  object-oriented  pro¬ 
gramming  language.  The  RTI  is  indifferent  to  how  the  federate- level  services  are  imple¬ 
mented.  In  fact,  current  proto-federations  refining  the  HLA  under  the  AMG  have  been 
implemented  in  a  wide  range  of  programming  languages,  to  include  C,  C++,  Ada, 
MODSIM,  Smalltalk,  and  even  FORTRAN. 

14.  Will  multiple  federations  reduce  interoperability? 

ANSWER:  The  HLA  explicitly  addresses  interoperability  among  simulations  in  a  single  federation, 
not  interoperability  between  distinct  federations.  However,  the  following  implicit  factors 
will  encourage  interoperability  between  federations. 

*  The  DIS++  Protocol  Catalog  will  provide  standard  attribute  and  data  definitions  for 
all  federations  to  use  in  their  FOMs.  All  federations  will  be  expected  to  use  these 
standard  definitions  to  the  maximum  extent  possible.  This  will  ensure  that  common 
attributes  (e.g.  location,  orientation)  have  common  representation  in  different  FOMs. 

*  DoD  will  maintain  an  on-line  library  of  FOMs  in  the  Modeling  and  Simulation 
Resource  Repository  (MSRR).  Such  FOMs,  or  components  of  them,  will  be  used  to 
build  new  FOMs,  thus  encouraging  interoperability  between  generations  of  FOMs. 

*  At  the  14th  DIS  Workshop,  it  was  suggested  that  DIS++  develop  core  or  "starter" 
FOMs  that  contain  a  standard  set  of  attribute  and  data  definitions  for  a  particular  si¬ 
mulation  domain.  Individual  federations  would  use  these  as  the  basis  for  develop 
FOMs  for  specific  federations.  This  will  encourage  common  data  representation  bet¬ 
ween  federations  in  the  same  domain. 

*  The  architecture  does  not  encourage  or  discourage  the  use  of  specific  FOMs.  The 
idea  of  a  set  of  reusable  “master”  FOMs  is  worth  pursuing. 

15.  Where  will  authority  to  change  HLA  reside?  How  is  the  DIS  Workshop  going  to  affect 
the  development  of  HLA  when  it  is  being  handed  over  to  a  contractor  to  develop? 

ANSWER:  The  HLA  is  not  being  handed  over  to  a  contractor  to  be  developed.  The  HLA  has  been 
developed  as  a  DoD  product,  and  as  such,  during  the  baseline  development,  authority  for 
changes  resides  at  DoD.  The  body  empowered  to  develop  the  HLA  is  the  DoD  Architec¬ 
ture  Management  group  (AMG).  The  membership  of  the  AMG  was  set  by  the  DoD  Exe¬ 
cutive  Council  for  Modeling  and  Simulation  (EXCIMS),  based  on  nominations  from  the 
Services  and  DoD  Agencies  involved  with  M&S  technology.  Aside  from  individual  name 
changes  due  to  personnel  changes  in  organizations,  during  the  prototyping  period  (at  least 
through  August  1996),  membership  of  the  AMG  is  fixed.  The  current  roster  of  AMG 
members  is  viewable  on  the  DMSO  Web  pages 
(http://www.dmso-mil/wrkgrps/amg/amgmcm.html). 

With  the  development  of  DIS++,  certain  components  of  the  HLA  (e.g.,  the  Interface 
Specification,  the  Object  Model  Template,  and  the  Protocol  Catalog)  are  expected  to  be 
standardized  through  the  DIS  Workshop  process.  Once  they  become  standards,  the  DoD 
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will  adopt  these  industry-based  standards  and  future  changes  to  the  standards  will  become 
the  responsibility  of  the  standards  body. 

Common  supporting  software  components  (e.g.,  versions  of  the  RTI,  HLA  interface 
modules)  may  be  procured  commercially,  although  they  will  be  based  upon  government 
specifications,  considering  the  work  of  the  standards  body. 

16.  Is  the  HLA  intended  to  be  an  IEEE  standard? 

ANSWER:  The  DIS++  Steering  Committee  will  form  working  groups  that  will  develop  draft  IEEE 
standards  based  on  the  baseline  HLA  definition.  These  documents  will  be  balloted  to  be¬ 
come  an  IEEE  Standard. 

17.  What  will  be  standardized  within  HLA?  How  will  the  RTI  be  configuration  managed  and 
controlled,  and  by  whom? 

ANSWER;  It  is  expected  that  certain  components  of  the  HLA  prescribed  in  the  baseline  definition 
will  be  standardized.  The  prototype  RTI  implementation  presently  being  tested  is  being 
developed  and  configuration  managed  by  a  Lincoln  Laboratory/Mitre  Corporation  team 
under  the  guidance  of  DMSO  and  the  AMG. 

i  8.  Where  is  the  master  document? 

ANSWER:  DMSO  currently  maintains  the  HLA  documentation.  All  HLA  documentation  is  available 
for  viewing  and  downloading  via  the  DMSO  home  page  on  the  World  Wide  Web 
(http://www, dmso.mil/).  This  includes  the  following: 

HLA  Management  Plan  (version  1.6) 

HLA  Interface  Specification  (version  0.4) 

HLA  Application  Programmer’s  Interface  (API)  (version  0.2) 

HLA  Object  Model  Template  (version  0.2) 

HLA  Time  Management  Design  Document  (version  0.21) 

HLA  Interface  Specification  Test  Procedures  (draft) 

Various  supporting  briefings,  both  technical  and  programmatic 

Text  documents  are  currently  stored  as  Microsoft  Word  documents  and  as  Adobe  Portable 
Document  Format  (PDF).  Briefings  arc  generally  in  Powerpoint  and  in  PDF,  although 
several  are  viewable  directly  onscreen  as  well.  In  addition,  at  the  bottom  of  most  of  the 
DMSO  HLA  Web  pages  there  is  an  e-mail  address  (hIa@msis.dmso.mil)  for  submitting 
comments  or  questions  about  the  contents  of  the  pages.  This  address  connects  to  person¬ 
nel  at  DMSO  who  review  the  questions  and  either  answer  directly,  or  pass  the  inquiry  to 
the  proper  person  to  provide  a  response. 

19.  What  is  the  schedule  for  HLA?  What  is  the  time  table  to  have  all  sims  running  HLA? 

What  is  the  transition  plan  for  current  DIS  users? 

ANSWER:  The  DoD  Modeling  and  Simulation  Master  Plan  calls  for  a  “review  [of]  all  ongoing  DoD 
M&S  projects  and/or  programs  by  second  quarter  FY  1997  for  feasibility  of  immediately 
adopting  the  HLA.  If  not  immediately  feasible,  these  reviews  shall  establish  the  date  by 
which  each  program  shall  comply.  If  a  specific  Mc&S  project  and/or  program  is  unable  to 
comply  with  the  HLA,  the  developing  Component  must  report  the  reason(s)  for  non- 
compliance  to  the  DDR&E,” 

See  answer  to  Questions  1 , 6,  and  7.  [DoD  5000. 59-P] 
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20.  Does  the  DoD  mandate  to  use  HLA  apply  to  legacy  models?  When  are  models  required 
to  use  HLA? 

ANSWER:  The  approved  DoD  Modeling  and  Simulation  Master  Plan,  under  Sub-Objective  1-1, 
prescribes  the  establishment  of  a  common  high-level  simulation  architecture  “to  which 
simulations  developed  by  particular  DoD  Components  or  functional  areas  must  conform.” 
The  Master  Plan  requires  DoD  components  review  their  ongoing  M&S  programs  by  se¬ 
cond  quarter  FY97  for  feasibility  of  immediate  HLA  compliance.  Legacy  systems  (i.e. 
those  existing  before  the  baseline  definition  of  the  HLA  is  promulgated)  will  be  examined 
on  a  case  by  case  basis.  Basically,  if  a  simulation  expects  to  interoperate  with  another  si¬ 
mulation  in  a  meaningful  way  once  the  HLA  is  set  in  place,  then  the  simulations  will  be 
required  to  become  HLA  compliant.  If  the  simulation  has  no  reason  to  interoperate  with 
another  simulation  (i.e.  it  is  fully  a  “stand-alone”  simulation),  then  it  could  potentially 
operate  without  the  HLA,  although  it  would  then  have  to  provide  for  itself  all  the  com¬ 
mon  infrastructure  which  the  HLA  makes  available  to  simulations.  We  expect  that  the 
cost,  schedule,  risk,  interoperability,  and  reuse  benefits  which  HLA  compliance  offers 
will  be  a  compelling  incentive  for  all  Program  Managers  to  adopt  the  HLA. 

21.  How  will  DoD  handle  converting  simulators  from  DIS  to  DIS++  so  that  simulators  can 
talk  to  each  other  (i.e.  some  simulators  will  be  using  DIS  and  some  using  DIS++)? 

ANSWER:  Under  the  HLA,  each  simulator  is  considered  a  federate.  As  such,  bringing  a  simulator 
into  compliance  with  the  HLA  will  be  treated  just  like  any  other  federate.  Current  proto¬ 
federations  involve  both  new  and  DIS-compliant  simulators,  so  relevant  data  will  be 
available  soon.  We  expect  commercial  DIS  to  DIS++  adapters  will  emerge  in  the  near 
future.  See  also  questions  19  and  20. 

22.  How  much  will  it  cost  to  convert  legacy  models  to  HLA?  What  are  the  potential  sources 
of  funding  to  convert  legacy  models  to  HLA? 

ANSWER:  The  cost  to  convert  legacy  models  to  HLA  will  vary  on  a  case  by  case  basis,  depending  on 
a  number  of  factors  such  as  the  original  engineering  design  of  the  model,  the  purpose  for 
which  it  is  being  adapted,  and  the  schedule  desired  for  the  adaptation.  Under  the  HLA 
prototype  effort,  roughly  25  individual  simulations  (or  “federates”)  are  being  designed  or 
adapted  to  the  HLA.  This  provides  a  number  of  case  studies  which  will  allow  a  better  as¬ 
sessment  of  the  potential  costs  involved  with  HLA  adaptation.  The  source  of  funding  is 
again  determined  on  a  case  by  case  basis. 

23.  Won’t  the  overhead  required  for  HLA  be  excessive  for  small  exercises? 

ANSWER:  There  is  no  reason  to  believe  that  the  overhead  for  small  exercises  will  be  “excessive”. 

The  proto-federations  testing  the  HLA  during  the  prototype  development  stage  (prior  to 
the  release  of  the  baseline  definition  in  August)  would  all  fall  in  the  category  of  “small 
exercise”  by  DIS  standards,  so  definitive  data  on  this  issue  should  be  available  soon.  See 
also  the  answer  to  question  8. 

24.  How  will  time  synchronization  issues  be  resolved? 

ANSWER:  The  HLA  Time  Management  Design  Document  (available  on  the  DMSO  Web  pages) 

details  a  number  of  time  management  services  which  are  reflected  in  the  latest  version  of 
the  HLA  Interface  Specification,  These  services  should  provide  the  mechanism  to  sup¬ 
port  meaningful  interactions  among  federates  with  different  time  management  require- 
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ments.  These  services  will  all  be  tested  by  the  HLA  proto-federations  prior  to  the  release 
of  the  HLA  baseline  definition. 

The  federates  and  the  RTI  both  rely  on  the  existence  of  wallclock  time  that  is  provided  by 
a  service  external  to  the  RTI  (and  federate).  Wallclock  time  is  assumed  to  be  available  on 
each  computing  platform  that  supports  a  component  of  the  RTI  or  a  federate.  The 
wallclock  time  access  mechanism  is  not  defined  by  the  HLA.  A  given  implementation  of 
the  RTI  and  all  the  federates  that  use  that  RTI  must  agree  on  the  source  of  wallclock  time 
for  each  type  of  computing  platform  and  the  mechanism  used  to  coordinate  wallclock  time 
among  all  cooperating  platforms.  The  mechanism  and  the  degree  of  coordination  are  po¬ 
tentially  important  to  the  success  of  a  given  federation  but  are  not  constrained  by  the  HLA 
specification. 

25.  What  about  security  in  HLA? 

ANSWER:  Security  issues,  particularly  multi-level  security  in  distributed  exercises,  transcends  the 
architecture,  DMSO  is  sponsoring  the  development  of  a  security  architecture  as  part  of 
the  HLA  development  program.  The  documentation  which  will  support  the  HLA  baseline 
definition  will  include  a  reference  security  architecture.  A  preliminary  description  of  that 
architecture  was  presented  at  the  1 4th  DIS  Workshop,  and  it  is  expected  that  such  techni¬ 
cal  interchanges  will  continue.  At  least  one  of  the  HLA  proto-federations  will  perform 
classified  exercises,  and  the  goal  is  to  define  the  HLA  such  that  it  does  not  preclude  wha¬ 
tever  is  required  to  address  multi-level  security  issues. 

26.  How  will  data  loggers/stealths/etc.  function  in  a  multi-cast  environment? 

ANSWER:  While  multicast  is  available  under  IEEE  1278.2  profile  2.  DIS  exercises  to  date  have  used 
broadcast  transmission  services  so  data  loggers  and  stealths  arc  always  receiving  a  stream 
of  data  on  all  players  at  all  times  during  the  exercise.  When  multicast  is  used,  this  will 
not  be  the  case. 

One  of  the  Simulation  Management  PDUs  in  DIS  2.x  commands  simulations  to  store 
given  data  locally  and  transmit  it  to  central  loggers  when  commanded  at  the  end  of  the 
exercise.  Under  DIS+-f-  multicast  operations,  loggers  will  probably  be  assigned  to  log 
data  on  the  multicast  groups  that  have  been  subscribed  to  by  the  simulations  physically 
located  near  it  and  to  transmit  this  data  to  a  central  logger  at  the  end  of  the  exercise  for 
merging  and  filtering.  The  stealth  viewer  can  subscribe  and  unsubscribe  just  like  any 
other  simulation.  Naturally,  there  will  be  some  redundant  data  and  it  will  have  to  be  filte¬ 
red  out  by  the  central  logger.  An  HLA  federation  could  have  one  data  logger,  but  this  may 
not  be  efficient  in  most  cases.  More  likely,  a  data  logging  function  will  have  to  collect 
and  collate  data  from  multiple  sources.  Other  more  elegant  solutions  than  the  one  descri¬ 
bed  above  are  likely  to  be  developed  over  time.  More  work  is  needed  in  this  area,  and  the 
Synthetic  Theater  of  War  (STOW)  program  (one  of  the  members  of  the  AMG)  is  actively 
pursuing  technical  solutions. 


DIS  2.x 

27.  Why  are  current  DIS  systems  being  referred  to  as  legacy  systems? 

ANSWER:  The  term  “legacy  system"  is  applied  to  any  simulation  which  will  be  designed  prior  to  the 
baseline  definition  of  HLA,  and  which  is  not  designed  to  lake  into  account  the  HLA  rules, 
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interface  specification,  etc.  It  is  intended  to  identify  those  DoD  simulations  which  may 
require  some  degree  of  modification  prior  to  being  incorporated  into  an  HLA  federation. 

28.  Will  we  continue  to  support  DIS?  For  how  long?  Will  we  add  to  2.x  standards  while 
DIS-i--}-  is  being  planned? 

ANSWER:  Any  document  submitted  and  approved  as  an  official  IEEE  standard  has  a  validity  period 
of  five  years  from  the  date  of  approval.  At  the  end  of  the  validity  period  the  document 
must  be  revised,  reaffirmed  by  ballot,  or  withdrawn.  The  workshop  process  currently  has 
three  documents,  IEEE  1278-1993,  1278.1-1995  and  1278.2-1995,  which  require  this 
nature  of  support.  In  addition,  the  Protocols  Working  Group  currently  has  underdeve¬ 
lopment  an  extension  to  IEEE  1278.1-1995.  This  extension  will  be  completed  through 
the  workshop  process,  and  should  complete  the  balloting  and  IEEE  approval  process  by 
mid-year  1997,  at  which  time  the  five  year  validity  period  will  begin  for  this  document. 
The  activity  in  support  of  maintaining  validation  of  our  IEEE  standards  constitutes  one 
level  of  continued  support  for  DIS  standards  needed  from  the  workshop. 

The  availability  of  funds  (see  answer  to  question  number  22)  and  the  support  available  to 
transition  HLA-Iegacy  systems  from  DIS  to  HLA-based  systems  will  define  the  amount 
and  extent  of  new  DIS  standards  development  that  will  continue.  The  requirement  is  that 
all  ongoing  DoD  M&S  projects  will  be  HLA  compliant.  DIS++  will  develop  and  main¬ 
tain  the  current  protocol  standards  I)  until  the  DoD  applications  using  them  can  transition 
to  HLA,  and  2)  while  needed  by  organizations  outside  of  DoD. 

29.  What  happens  to  my  current  investment  in  DIS  2.x? 

ANSWER:  The  global  transition  from  DIS  2.x  to  an  HLA  compliant  structure  will  be  a  process  which 
occurs  over  time.  Depending  upon  the  timetable  within  the  community  with  which  you 
interact  or  federate,  you  may  get  appreciable  benefit  out  of  your  investment  prior  to  con¬ 
version.  Your  future  investment  decisions  need  to  be  influenced  accordingly. 

30.  My  company  has  two  very  specific  purpose  type  simulators  which  have  been  actively 
used  in  recent  DIS  demonstrations  and  exercises.  Will  we  be  excluded  from  further  parti¬ 
cipation  because  we  do  not  have,  and  do  not  have  the  internal  resources  to  develop,  an 
RTI  interface? 

ANSWER:  There  will  continue  to  be  DIS  exercises  run  during  the  period  of  transition.  Also,  there  are 
DIS  to  HLA  conversions  being  developed  to  support  DIS  and  even  SIMNET-based  fede¬ 
rates  in  the  current  HLA  proto-federations,  which  suggest  that  commercial  products  will 
become  available  to  ease  the  transition  from  DIS  to  HLA  for  companies  such  as  yours. 

See  also  question  21 . 

31.  What  will  happen  to  all  the  DIS  tools  that  have  been  developed  (i.e.  XCIU,  Data  loggers, 
data  analysis  tools,  etc.)?  Who  will  pay  to  have  these  converted  to  HLA? 

ANSWER:  Modification  of  some  existing  tools  and  development  of  new  ones  has  already  begun  as 

part  of  the  work  within  the  HLA  proto-federations.  However,  future  users  of  the  HLA  will 
continue  to  have  to  support  the  development  of  the  full  complement  of  tools  required  for 
HLA,  Just  as  they  did  to  support  the  maturation  of  DIS.  Much  of  what  has  been  developed 
for  DIS  will  ease  the  way  for  developing  similar  capabilities  to  support  the  HLA. 
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32.  My  simulator  is  about  to  start  testing  by  means  of  the  DIS  Test  Suite.  Will  there  be  any 
significant  value  in  passing  the  tests  of  this  test  suite  in  the  new  HLA-based  paradigm? 

ANSWER:  The  primary  value  will  be  in  the  ability  it  will  afford  to  be  able  to  participate  confidently 
in  such  DIS  exercises  as  may  occur  before  you  are  called  upon  to  federate  in  an  HLA  en¬ 
vironment.  Passing  the  test  also  provides  evidence  that  your  simulator  is  a  candidate  for 
possible  inclusion  in  future  HLA  federations. 

33.  Should  1  finish  my  2,x  document? 

ANSWER:  DIS  has  concentrated  on  real-time  virtual  and  live  simulations  at  the  tactical  level  in  the 

past.  DlS-i-f-  will  expand  to  serve  other  communities  as  well.  During  the  transition  period 
to  DIS++,  the  real-time  virtual  and  live  simulations  will  continue  to  operate  and  can  be¬ 
nefit  from  the  DIS  2.x  documents  currently  being  developed.  In  addition,  most  of  these 
simulations  will  continue  to  operate  when  modified  to  implement  DIS++  principles.  Con¬ 
sequently,  the  information  contained  in  the  DIS  2.x  documents  may  be  useful  in  the 
DIS-I-+  arena. 

If  a  document  is  near  completion,  it  should  be  finalized  and  considered  as  a  resource  for 
the  development  of  DIS-(-i-  documents  to  be  started  soon.  If  the  document  is  longer  term, 
then  the  DIS-i-f-  Steering  Committee  will  consider  it  for  expansion  and  modification  to  in¬ 
corporate  DlS-h-i-  concepts. 


DIS++ 

34.  What  is  DIS+-!-?  What  are  the  differences  between  HLA  and  DIS++?  Is  DIS++  an 

implementation  of  HLA? 

ANSWER:  As  stated  in  the  registration  handout  at  the  1 4th  Workshop,  the  name  DIS+-I-  has  been 
chosen  to  communicate  the  essential  objective  of  expanding  the  standards  development 
activities  to  include  both  the  High  Level  Architecture  and  other  members  of  the  modeling 
and  simulation  community.  DIS++  refers  to  the  evolution  of  the  DIS  standards  to  cover 
areas  of  modeling  and  simulation  identified  in  the  DIS  Vision  document  but  not  addres¬ 
sed  in  the  current  standards  (e.g.  event  driven  simulations,  analytic  models,  interfaces  to 
operational  systems),  HLA  is  an  explicit  architecture  being  developed,  and  currently  ow¬ 
ned,  by  DoD  to  provide  a  common  framework  for  the  development  of  all  DoD  modeling 
and  simulation.  To  prove  that  the  HLA  is  a  viable  concept,  DoD  is  sponsoring  the  deve¬ 
lopment  of  prototype  implementations  of  the  HLA.  See  answers  to  Questions  1, 3.  4,  5, 

1 1,  and  12. 

DIS++  standards  development  will  be  conducted  by  the  standards  development  organiza¬ 
tion  and  processes  resulting  from  implementing  the  plan  prepared  by  the  current  Special 
Task  Group  for  Vision  Implementation  Plan  (STGVIP) ,  The  D1S++  standards  workshop 
will  assume  responsibility  for  standardization  of  the  main  components  of  the  baseline 
HLA  and  other  standards  important  to  the  M&S  community  as  part  of  the  normal 
standards  development  process.  The  DIS++  standards  body  will  also  expand  the  DIS 
DD/PC  (Data  Dictionary/Protocol  Catalog)  to  include  common  data  structures  needed  by 
DIS++  applications.  This  expanded  product  will  called  simply  the  DIS++  Protocol  Cata¬ 
log.  See  answers  to  questions  16,  17,  18,  36.  and  4 1 . 
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35.  Is  HLA  or  DIS++  a  protocol? 

ANSWER:  HLA  is  an  architecture,  defined  by  an  interface  specification  (with  corresponding  API),  an 
object  model  template,  and  a  set  of  underlying  technical  principles  (rules).  DIS++  is  a  set 
of  standards  supporting  this  architecture.  It  is  envisioned  that,  during  the  design  and  im¬ 
plementation  of  an  HLA  federation,  certain  resources,  such  as  a  Protocol  Catalog  (an  ex¬ 
tension  of  the  DIS  Data  Dictionary/Protocol  Catalog)  will  be  available  through  on-line 
repositories. 

36.  Is  DIS  3.0  =  HLA?  Is  there  going  to  be  a  DIS  3.0? 

ANSWER:  There  will  not  be  a  DIS  3.0,  in  the  sense  of  another  DIS  generation  between  the  current 
2.x  standard  and  the  HLA  compliant  version.  Future  evolution  of  DIS  is  denoted  DIS+-I-. 
The  architecture  adopted  for  DIS-I-+  is  HLA. 


Questions  &  Comments  Related  to  VIP  and  Standards 

37.  Don’t  you  think  the  stated  schedule  for  reorganization  is  insane? 

ANSWER:  No.  The  revised  organization  will  undoubtedly  evolve  over  time,  and  it  is  important  that 
we  START  the  process  soon.  With  the  availability  of  the  HLA  baseline  definition  in  Au¬ 
gust,  there  is  an  opportunity  to  begin  work  at  the  September  Workshop,  and  we  don’t 
want  to  miss  that  opportunity.  While  the  details  of  transition  to  DIS++  await  the  recom¬ 
mendations  of  the  STG  VIP,  the  desire  is  for  a  close  working  relationship  between  the  de¬ 
velopers  of  the  HLA  and  the  IEEE  standards  body. 

38.  Have  we  given  up  on  the  entertainment  industry? 

ANSWER:  DIS  and  the  entertainment  industry  have  many  common  interests  and  this  area  of  commo¬ 
nality  is  growing.  Companies  and  individuals  developing  VR  (Virtual  Reality)  applica¬ 
tions  for  the  Internet  are  creating  a  set  of  standards  called  VRML  (Virtual  Reality  Mode¬ 
ling  Language)  to  meet  their  specific  needs.  There  is  an  overlap  in  membership  between 
the  VRML  and  DIS  communities.  VRML  and  other  entertainment  industry  speakers  have 
participated  in  the  last  two  DIS  workshops.  To  make  the  link  between  the  communities  a 
bit  more  formal,  the  DIS  Coordinating  Committee  has  invited  a  member  of  the  VRML 
Architecture  Group,  the  equivalent  of  the  DIS  Steering  Committee,  to  be  a  member  of  a 
panel  reviewing  DIS++  reorganization  plans.  DoD  is  also  aggressively  pursuing  opportu¬ 
nities  for  cooperation  with  the  entertainment  industry. 

39.  Have  we  backed  away  from  an  international  standard?  Are  we  targeting  ISO  with  our 
standards? 

ANSWER:  No.  DIS  continues  to  consider  its  objective  international  standards,  and  the  Modeling  and 
Simulation  Master  Plan  calls  for  the  establishment  of  international  standards  (e.g.  ISO)  in 
addition  to  IEEE  standards.  However,  going  directly  to  an  ISO  standard  is  a  lengthy  and 
costly  process.  Going  first  to  an  IEEE  standard  creates  a  “fast  path”  to  an  ISO  standard. 
The  DDR&E  also  recently  invited  liaison  within  NATO  regarding  the  HLA  development 
process.  The  HLA  products  are  being  made  available  largely  through  the  Internet,  which 
is  international  in  scope.  While  there  are  still  certain  restrictions  (external  to  the  HLA 
development  process)  which  may  restrict  the  unlimited  distribution  of  certain  software 
components,  the  goal  is  to  make  the  HLA  as  widely  available  as  possible. 
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40.  Will  we  have  requisite  support  for  conferences/workshop? 

ANSWER:  There  is  strong  support  for  the  involvement  of  the  DIS  community  in  the  development  of 
the  HLA  from  the  highest  levels  of  the  DoD.  The  evolution  from  DIS  2.x  to  DIS++  will 
actually  broaden  the  base  of  support  for  the  Workshops,  since  DoD  M&S  communities 
which  previously  were  not  strongly  supported  under  DIS  2.x  will  now  have  a  role.  This 
broadening  of  scope  will  call  for  a  reorganization  of  the  structure  of  the  workshops,  and 
this  will  strengthen  the  standards  process.  DMSO  intends  to  continue/enhance  its  finan¬ 
cial  support  to  the  DIS  standards  organization. 

41.  What  are  the  futures  of  the  current  workgroups  at  the  workshops? 

ANSWER:  The  current  workgroups  are  oriented  around  real-time  virtual  and  live  simulations  at  the 
tactical  level.  As  we  expand  our  goals  to  serve  a  broader  modeling  and  simulation  com¬ 
munity,  one  option  is  to  simply  invite  members  of  these  communities  to  join  our  current 
working  groups.  However,  many  DIS++  concepts  do  not  fit  neatly  into  the  current  work¬ 
groups. 

The  DIS  Steering  Committee  voted  to  reorganize  the  workshops  around  the  products  that 
will  be  needed  to  implement  DIS++.  We  will  be  forming  workgroups  to  standardize  these 
products.  Naturally,  many  DIS  2.x  goals  will  still  be  goals  in  DIS++.  Consequently,  some 
of  the  future  workgroups  will  be  similar  to  the  current  groups  but  with  a  broader  mission 
and  new  participants. 

Current  workshop  participants  should  rest  assured  that  there  will  be  ample  opportunity  to 
volunteer  their  time  and  energy  and  have  an  impact  on  the  development  of  DIS-h-i-  pro¬ 
ducts. 


Compliance 

42.  How  do  wc  determine  compliance? 

ANSWER:  The  DoD  M&S  Master  Plan  describes  compliance  in  terms  of  the  High  Level  Architecture 
(HLA).  The  AMG  is  preparing  a  definition  of  HLA  compliance  as  part  of  the  baseline 
definition.  The  current  thought  is  that  HLA  compliance  deals  with  how  well  a  federate 
handles  the  functions  defined  in  the  HLA  interface  specification,  whether  it  has  an  object 
model  in  conformance  with  the  OMT.  and  whether  it  complies  with  the  HLA  rules  for  fe¬ 
derates.  This  is  distinct  from  Federation  testing,  which  is  the  responsibility  of  individual 
federations.  See  answers  to  Qestions  II  &  12.  Corresponding  compliance  definitions  and 
test  procedures  will  be  included  as  an  integral  part  of  DIS++  standards  development .. 


Getting  Information  and  Answers 

43.  How  do  wc  get  more  information? 

ANSWER:  Current  information  about  the  full  range  of  DoD  M&S  activities  is  available  on  the 

DMSO  home  page:  http://www.dmso.mil/.  Current  information  on  the  status  and  pro¬ 
gress  of  the  HLA  development  is  available  from  the  home  page  or  more  directly  at 
http://www.dmso.mil/projects/hIa.  These  pages  contain  literally  hundreds  of  pages  of  in¬ 
formation,  both  in  technical  documentation  and  in  briefing  materials,  describing  the  van- 
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ous  aspects  of  the  HLA.  At  the  bottom  of  most  of  the  DMSO  HLA  Web  pages,  there  is 
an  e-mail  address  (hIa@msis.dmso.mil)  for  submitting  comments  or  questions  about  the 
contents  of  the  pages.  This  address  connects  to  personnel  at  DMSO  who  review  the 
questions  and  either  answer  directly,  or  pass  the  inquiry  to  the  proper  person  to  provide  a 
response. 

Current  information  about  activities  conducted  by  the  DIS  Standards  Workshop  is 
available  at  the  1ST  Service  Center  home  page:  http://www.sc.ist.ucf.edu/~STDS/ .  Infor¬ 
mation  on  the  status  and  progress  of  the  Special  Task  Group  Vision  Implementation  Plan 
(STGVIP)  is  available  from  the  home  page  under  Files  and  Documents  (FTP  Area  with 
titles.)  or  more  directly  at  http://ftp.sc.ist.ucf.edu/STDS/stgvip.  Comments  or  questions 
concerning  STGVIP  reports  and  activities  may  be  provided  using  the  DIS-STD-STGVIP 
reflector.  To  subscribe  to  the  STGVIP  reflector,  send  an  e-mail  message  to 
“listproc@sc.ist.ucf.edu”.  The  subject  may  be  anything  you  wish,  but  the  body  of  the 
message  MUST  have  ONLY  ONE  LINE  as  follows: 

“subscribe  DIS-STD-STGVIP  First  Last”  with  your  first  and  last  name  entered  in  place 
of  First  and  Last  as  shown.  Do  not  include  the  quotation  marks  in  the  address  or  body  of 
the  message. 

Aside  from  face  to  face  presentations  at  conferences  such  as  the  DIS  Workshop,  the  best 
clearinghouse  of  information  on  the  HLA  and  STGVIP  activities  are  these  pages  and  re¬ 
flectors. 
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Bijiage  C  DIS++  Transition  Frequently  Asked  Questions 
(11/96) 


Topics 

Transition 

Workshops  /  Conferences 
Standards 
Projects  /  Groups 
PIS  FOM 


OMT 

Community 

Processes 

Information  Technology 


Transition 

•  Question: 

How  long  will  it  take  for  the  dust  to  settle  from  around  this  newborn  DIS+-f  so  that  we  can  get  on 
with  the  detailed  business  of  promoting  interoperability  and  distributed  simulation? 

Answer: 

The  Transition  Team  will  stand  up  SAC  and  CC  by  March  ’97 

•  Question: 

If  I  were  to  develop  some  novel  protocol  element  for  DIS++,  I  would  want  as  many  people  as 
possible  to  start  using  it  as  soon  as  possible  (cf  WWW/Java)  -  this  would  bring  greatest  commer¬ 
cial  advantage  to  me  in  the  short  term.  Will  the  DIS++  organization  help  or  hinder  me  in  this  ef¬ 
fort?  How  would  it  do  so? 

Answer: 

In  general  the  conference  will  be  an  excellent  platform  for  you  to  publicize  your  ideas  in  po¬ 
sition  papers  and  expose  them  to  your  peers  for  evaluation  and  refinement.  In  addition, 

DIS+-H  conferences  will  have  vendor  displays  where  you  may  demonstrate  products,  techni¬ 
ques,  or  ideas.  The  only  limiting  factor  will  be  fees  and  the  availability  of  facilities. 

DIS++  email  reflectors  will  provide  another  avenue  for  promulgating  products,  techniques, 
and  ideas. 

•  Question: 

Since  the  purpose  of  the  Transition  Team  seems  to  be  to  determine  the  future  of  HLA  in  terms  of 
the  preparation  of  standards  for  its  use  and  the  policies  governing  the  organization  of  the  federa¬ 
tions,  shouldn’t  there  be  an  "Implementation  Representative"  on  the  Transition  Team?  This  person 
would  be  able  to  help  users  in  the  short  term,  with  lessons  learned  and  to  provide  a  conduit  for 
information  exchange  between  HLA  implementers. 

Answer: 

The  purpose  of  the  Transition  Team  is  NOT  to  determine  the  future  of  the  HLA  (or  DIS  for 
that  matter).  The  actual  purpose  of  the  Transition  Team  is  to  create  the  workspace  (both  phy¬ 
sical  and  virtual)  for  the  future  HLA  and  Distributed  Simulation  work  to  continue.  That  future 
work  will  include  development  and  ratification  of  products  such  as  standards,  guides,  ratio¬ 
nale,  conference  proceedings,  etc.  The  future  work  related  to  the  development  of  these  pro¬ 
ducts  is  not  going  to  be  accomplished  by  the  Transition  Team  as  a  whole;  rather,  the  work 
will  continue  to  be  accomplished  by  the  practitioners,  users  and  theoreticians  who  have  done 
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SO  in  the  past. 

However,  the  work  of  the  Transition  Team  does  play  an  important  role  in  the  development  of 
these  products.  The  conference  structure  must  provide  both  physical  and  virtual  space  for  the 
groups  to  meet  to  continue  the  work  of  both  HLA  and  DIS,  while  ensuring  that  they  travel  the 
same  path.  In  addition,  space  must  be  provided  to  allow  the  users  and  practitioners  to  provide 
inputs  on  both  good  and  bad  past  experiences,  as  well  as  communicate  their  needs  and  cor¬ 
rections  for  the  future. 

In  addition,  the  Transition  Team  will  provide  for  initial  Standards  Development  Groups 
(SDGs)  to  carry  on  with  the  work  in  progress  done  to  date  by  HLA  groups  and  DIS  groups, 
but  is  not  yet  in  final  form.  As  time  progresses,  and  needs  are  expressed,  additional  groups 
will  be  formed  (and  disbanded  once  work  is  accomplished)  to  fulfill  the  needs  expressed  by 
the  users. 

The  Transition  Team  is  not  composed  of  "specialty  areas",  such  as  implementation;  and  there 
was  little  or  no  thought  given  to  the  composition  of  the  Transition  Team  regarding  specialty 
areas.  Rather,  the  Transition  Team  was  chosen  from  a  group  of  individuals  interested  in  see¬ 
ing  DIS  and  HLA  progress  together  as  complementing,  rather  than  opposing  technologies. 

For  the  interim,  the  users  should  seek  out  the  past  protofederations  and  experimenters  for 
their  lessons  learned  and  guidance  for  the  interim.  DMSO  is  the  best  place  to  start  for  such 
help.  Once  the  conference  takes  shape,  a  space  will  be  provided  for  the  users  and  implemen- 
ters  to  meet  with  those  users  of  the  technology  (just  as  it  occurs  in  DIS).  If  the  need  arises  for 
more  formal  gatherings,  either  after  the  initial  DIS++  conference,  or  prior  to  its  inception,  a 
process  will  be  established  (by  the  Transition  Team)  to  allow  those  meetings  to  occur. 

Again,  let  me  emphasize  that  the  purpose  of  the  Transition  Team  is  to  develop  the  structure  of 
the  conference  and  working  teams  in  such  a  way  as  to  allow  the  ongoing  HLA  (  and  DIS) 
work  to  continue  and  progress  effectively. 


Workshops  /  Conferences 

•  Question: 

What  will  future  DIS+-}'  conferences  look  like? 

Answer: 

2  conferences  per  year  (Sept  and  March) 

Every  conference  would  include 

1  day  of  User  Community  Forum 

2  days  of  Specialty  Area  Forums 

Reports  from  the  SDGs  to  the  relevant  forums 
TTT  formed  to  address  issue 

•  Question: 

Is  the  semiannual  Orlando  gathering,  formerly  known  as  "Workshop  on  Standards  for  the  Intero¬ 
perability  of  Distributed  Simulations,"  going  to  continue  to  be  a  Workshop? 

Answer: 

Whether  or  not  it  will  be  a  "workshop"  or  a  "conference"  is  being  debated  and  whatever 
choice  is  made  will  take  into  account  the  concern  about  getting  permission  and  funding  to  at¬ 
tend. 
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•  Question: 

If  the  DIS  Workshops  end,  so  ends  the  EMF  group.  How  do  we  (as  individuals)  get  from  here  to 
the  next  incarnation?  Who  will  lead  the  next  work  group  (assuming  our  projects  are  accepted)? 
We  had  staff  support  from  1ST  (Dr.  Paris).  Might  that  continue? 

Answer: 

As  stated  in  the  VIP,  standards  groups  will  receive  support  from  the  support  group  as  EMF 
has  in  the  past.  The  successor  organization,  whatever  it  is  called,  should  start  meeting  in 
March. 

•  Question: 

If  the  Workshop  series  ends  with  the  15th,  will  it  be  necessary  to  attend  both  its  successors  —  the 
conference  and  the  working  groups?  The  reason,  of  course,  is  that  payers  of  per  diem  may  be 
happier  paying  for  working  sessions  than  for  conferences,  but  if  truly  important  things  occur  at 
the  conference  it  will  be  necessary  to  attend  that  too. 

Answer: 

Hopefully,  the  amount  of  travel  will  be  no  higher  than  it  is  now,  with  standards  activity  repla¬ 
cing  interim  meetings.  The  conference  will  provide  the  technical  engine,  membership  and 
electorate  for  the  standards. 


Standards 


•  Question: 

What  is  going  to  be  standardized? 


Answer: 

The  HLA  IF  Spec,  and  OMT  will  be  the  initial  new  DIS++  standards.  A  standard  for  repre¬ 
senting  the  natural  environment,  SEDRIS,  has  been  identified  as  a  potential  standard.  A  new 
version  of  the  IEEE  1278.1  standard  will  be  balloted.  Other  standards  will  be  established  as 
requirements  for  them  emerge  from  the  M&S  community  through  the  DIS++  conference.  A 
process  for  identifying  and  developing  such  standards  is  a  key  part  of  DIS++. 

•  Question: 

How  will  new  people  know  how  to  get  plugged  into  the  standards  development  process? 

Answer: 

The  best  approach  is  to  get  involved  in  the  Workshop  Forum(s)  of  interest  to  them.  These  Fo¬ 
rums  are  where  new  ideas  and  problem  issues  are  surfaced  and  debated,  and  from  which  pro¬ 
posals  for  new  standards  or  modifications  to  standards  will  arise.  Once  the  CC,  EXCOM,  and 
SAC  have  approved  a  particular  item  to  become  a  DIS++  product,  there  will  be  additional 
opportunity  to  participate.  The  Forum  members  w’ill  be  the  primary  source  to  which  the 
Standards  Actitvity  Committee  will  come  to  seek  volunteers  to  write  and  review  the  product 
as  the  product  matures.  Each  Forum  will  have  an  associated  email  rcHector;  subscribing  to 
this  reflector  will  automatically  enroll  a  person  as  a  member  of  that  Forum. 


Question: 

Is  its  focus  to  remain  on  standards  for  interoperability?  or  is  it  expanding  to  include 
other/different  issues  (reuse,  etc.)? 
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Answer: 

The  desire  is  to  expand  the  scope  to  include  other  issues  as  well  as  "interoperability". 

•  Question: 

Will  there  be  standardized  interfaces  to  legacy  systems? 

Answer: 

HLA-DIS  and  HLA-ALSP  interfaces  have  been  identified  and  designed  at  a  functional  level. 
DIS++  standardization  of  such  products  is  being  considered.  Such  standardization  depends 
largely  on  requirements  that  emerge  from  the  M&S  community  through  the  DIS++  confe¬ 
rence. 

•  Question: 

Will  there  be  further  development  /support  for  the  existing  DIS  standards? 

Answer: 

Yes.  One  more  revision  of  IEEE  1278  series  will  be  balloted  via  the  IEEE  process.  The  DoD 
HLA,  and  associated  DIS++  standards,  will  supersede  the  1278  series  over  the  next  few  years 
as  the  HLA  and  related  standards  mature.  Further  development  of  DlS-Iike  (e.g.  message  ba¬ 
sed  protocols)  standards  will  be  undertaken  as  requirements  for  them  emerge  from  the  M&S 
community  through  the  DIS++  conference. 

•  Question: 

There  appears  to  be  a  persistent  desire  to  maintain  formal  control  on  the  definition  and  use  of 
DIS++  standards  -  ie  to  be  official  DIS++,  your  proposals  must  go  through  the  formally  defined 
procedures.  What  is  the  position  on  control  and  use  of  DIS++  standards? 

Answer: 

Control  of  DIS-1-+  standards  by  the  organization  will  extend  to  their  development  within  the 
organization  and  to  their  advertised  use.  That  is,  vendors  may  not  claim  that  their  products  are 
compliant  or  compatible  with  DIS++  standards  without  approval  by  the  DIS++  organization. 

The  DIS++  organization  is  an  independent  standards  development  body  and  a  forum  for  ex¬ 
change  of  related  information.  It  cannot  require,  advocate,  or  prohibit  the  use  of  DIS-I-+ 
standards  in  any  simulation  application.  The  use  or  approval  of  a  particular  standard  in  an  ap¬ 
plication  will  be  determined  by  the  policies  of  the  organization  responsible  for  that  applica¬ 
tion. 

The  HLA  situation  is  an  example.  The  HLA  is  being  developed  by  the  US  DoD  with  partici¬ 
pation  by  key  members  of  the  DIS  community.  At  a  time  to  be  determined  during  the  transi¬ 
tion  period,  the  DIS+-1-  organization  will  assume  responsibility  for  maintenance  of  several  key 
components  of  the  HLA  (e.g.  Interface  Specification  and  Object  Model  Template)  and  will 
establish  them  as  DIS++  standards.  However,  the  requirement  to  use  these  standards  in  US 
military  simulations  will  be  determined  by  DoD.  not  DIS++. 


Projects  /  Groups 

•  Question: 

What  happens  to  the  existing  DIS  working  groups? 
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Answer: 

All  existing  groups  were  disbanded  as  of  the  1 5th  workshop  (Sept  96) 

The  TT  will  develop  charters  for  the  new  Executive  Committee,  Conference  Committee, 
and  Standard  Activities  Committee  will  oversee  elections  before  the  March  Conference 
New  groups  will  be  formed  under  the  new  structures 
Most  focus  groups  will  map  to  User  Community  Forums 
Most  WGs  and  SIGs  will  map  to  Specialty  Area  Forums 

•  Question: 

What  will  happen  to  ongoing  projects,  such  as  those  involved  in  FDR  or  protocol  writing,  and 
more  to  the  point,  our  efforts  to  refine  the  EMF  process  descriptions? 

Answer: 

The  Transition  Team  will  oversee  any  transition  groups  that  are  completing  tasks. 

•  Question: 

The  EMF  group  appears  to  have  two  projects  on  the  horizon  -  the  engineering  standard  (Brett 
Butler)  and  the  DIS++  process  model  (Bob  Lutz).  Do  we  expect  others  in  the  near  future? 

Answer: 

Process  and  automation  discussion  and  standardization  will  be  increasingly  important.  Consi¬ 
deration  is  being  given  to  having  a  forum  to  address  this  area. 


DIS  FOM 

Question: 

•  An  important  issue  in  the  transition  from  DIS  to  DIS++.  is  the  issue  of  a  DIS  FOM.  Clearly,  it 
will  be  very  useful,  and  perhaps  necessary,  to  have  an  encoding  of  the  DIS  standard  in  OMT  for¬ 
mat.  (In  fact,  it  is  my  opinion  that  in  a  HLA  world,  DIS  is  a  federation,  albeit  a  big  and  important 
one.)  We  have  already  been  made  aware  of  the  existence  of  several  DIS  FOMs. 

Can  the  TT  assemble  a  complete  list  of  DIS  FOMs  in  existence,  under  construction,  or  planned, 
and  define  their  differences? 

Answer: 

FOMs  were  derived  in  part  from  DIS  standard  protocols  for  the  Platform,  T&E,  and 
JPSD/IEC  HLA  protofederations.  The  FOMs  are  available  for  examination  from  those  proto- 
federations.  No  comparison  of  those  FOMs  has  been  made  or  published.The  DIS  Protocols 
WG  has  embarked  on  an  effort  (Richard  Schaffer  lead)  to  convert  the  existing  1278.1  proto¬ 
cols  and  enumeration  data  into  a  DIS  FOM  (known  as  the  Plug  'n  Play  FOM).  DMSO  is  coo¬ 
perating  in  this  effort.  The  results  will  be  available  for  examination  and  discussion  at  the 
March  97  conference 

•  Question: 

Does  the  TT,  the  SC,  or  the  larger  DIS  community  have  any  plans  to  elevate  one  of  those  DIS 
FOMs,  or  a  combination  of  them,  to  the  status  of  standard,  i.c.  as  part  of  the  DIS  standard? 

Answer: 

No  serious  studies  have  been  conducted,  no  recommendations  have  been  brought  forward, 
and  no  decisions  have  been  made  regarding  the  development  and  standardization  of  a  DIS 
FOM.  However,  this  is  a  growing  area  of  interest  and  will  demand  attention  in  the  near  future. 
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•  Question: 

If  so,  how  will  the  standard  DIS  FOM  be  selected? 

Answer: 

The  issue  of  FOM  standardization  depends  on  what  emerges  from  the  M&S  community 
through  the  DIS++  conference  discussions.  The  community  needs  to  decide  whether  there  is 
one  or  a  set  of  FOMs  they  want  to  standardize,  and  if  a  set  what  the  members  should  be.  Once 
that  is  decided,  then  the  DIS++  conference  and  standards  process  can  be  used  as  appropriate. 

•  Question: 

Will  a  standard  DIS  RID  also  be  constructed? 


Answer: 

The  RID  will  probably  not  be  a  DIS++  standard.  The  RID  is  RTI  specific.  It  might  make 
sense  to  standardize  some  RID  contents  across  all  RTIs  or  possibly  within  communities,  but 
in  addition  to  some  standard  information,  a  particular  RTI  may  require  some  information  for 
optimization,  etc.  Hopefully,  even  if  we  do  not  standardize  RID  information,  a  RID  Data  In¬ 
terchange  Format  (DIF)  might  become  DIS++  standards  so  tools  could  be  developed  which 
could  produce  the  information  required  by  a  RID  and  then  a  specific  RID  reader  could  con¬ 
sume  the  information. 

♦  Question: 

What  will  be  Standardized?  FOM's?  SOM's?  OMT?,  HLA  itself? 


Answer: 

The  HLA  interface,  the  OMT  and  the  architecture  (possibly  containing  the  rules)  will  be  the 
first  initial  set  of  HLA  related  DIS++  standards.  SOMs  will  probably  not  become  DIS++ 
standards,  but  it  is  likely  that  community  FOMs  might  emerge  from  the  M&S  community 
through  the  DIS++  conference  and  be  considered  as  DIS++  standards. 


OMT 

•  Question: 

Is  the  OMT  complete?  To  the  level  of  Balloting? 

Answer: 

The  OMT  is  not  complete  in  the  absolute  sense  since  there  are  several  additions  to  it  being 
explored  by  the  DoD  AMG  and  as  the  larger  community  begins  to  use  it,  they  will  find  addi¬ 
tional  improvements  worthy  of  standardization.  On  the  other  hand,  what  is  there  has  been 
used  by  the  protofederations  and  therefore  has  enough  maturity  to  initiate  the  standardization 
process. 

•  Question: 

Has  it  been  interpreted  by  people  who  did  not  write  it? 

Answer: 

The  users  in  the  protofederations  were  not  the  authors  of  the  OMT.  The  protofcdcrations  all 
had  representatives  on  the  AMG  OMT  working  group,  and  therefore  the  results  of  their  expe¬ 
rience  using  the  OMT  were  included  in  the  1 .0  version  approved  by  the  AMG. 
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Community 

•  Question: 

What  are  we  (the  DIS  ++  community)  trying  to  achieve? 

Answer: 

The  fundamental  purpose  for  the  reorganization  of  the  DIS  workshop  is  to  expand  the  scope 
of  the  DIS  standards  to  serve  M&S  communities  outside  of  the  original  real-time  platform  le¬ 
vel  simulations  that  were  the  origins  of  DIS.  To  do  this  DIS++  will  embrace  the  DoD  HLA 
and  develop  standards  for  it.  The  HLA  provides  a  general  structure  that  will  permit  different 
kinds  of  simulations  to  interoperate.  The  DIS++  conference  or  workshop  will  have  some  edu¬ 
cation  aspects.  The  major  user  (DoD)  will  have  it's  own  outreach  and  training. 

•  Question: 

How  are  the  people  in  the  DIS  community  going  to  transition  to  the  new  way  of  thinking?  This 
includes  end  users  as  well  as  developers  and  standards-setters.  The  DIS  community  is  many  times 
bigger  than  those  who  attend  the  workshops. 

Answer: 

The  DIS++  Outreach  will  be  proactive.  DIS++  will  encourage  participation  from  other  M&S 
communities  via  an  outreach  program  that  will: 

1 .  invite  key  individuals  from  other  professional/standards  bodies  to  participate  on  DlS+4- 
committees 

2.  encourage  the  formation  of  groups  within  other  professional/standards  bodies  to  address 
DIS++  needs 

3.  sponsor  conferences  on  specific  subjects  to  supplement  the  semi-annual  conferences.The 
vision  is  not  to  become  the  center  of  the  M&S  universe  but  to  be  a  crossroads  where  all 
the  components  of  the  M&S  community  can  come  to  share  ideas,  needs,  questions,  and 
answers. 

•  Question: 

Who  is  the  ultimate  end-user  community?  Is  it  big  government  programs  or  millions  of  low  bud¬ 
get  home  users  using  28.8kbps  modems  on  486AVindows  platforms  and  wanting  new  thrills  every 
month  (Which  market  is  bigger?  and  which  will  ultimately  set  the  standards?). 

Answer: 

Today  the  dominant  customers  of  standards  for  distributed  simulation  are  military  organiza¬ 
tions.  However,  many  within  the  DIS/HLA/DIS++  community  feel  that  distributed  real-time 
simulation  over  the  Internet  may  be  the  next  'killer  application'  for  computers.  Multi-player 
games  (some  of  which  use  DIS  standards)  are  already  quite  popular. 

VRML  (Virtual  Reality  Modeling  Language)  is  a  major  force  in  setting  standards  for  distri¬ 
buted  simulation  via  the  Internet.  Links  arc  already  being  forged  between  the  DIS+-H  and 
VRML  communities.  We  hope  to  expand  these  links  via  the  DIS+-!-  outreach  program. 

•  Question: 

My  lasting  impression  from  reading  the  VIP  is  that  the  community  seems  to  be  addressing  in  what 
form  the  community  should  continue  and  the  processes  and  structures  by  which  it  can  keep  itself 
employed.  How  will  the  application  of  DIS/DIS-i“+  be  encouraged,  developed  and  supported  in 
the  future? 
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Answer: 

1 .  DIS++  will  be  expanded  to  include  as  much  of  the  M&S  community  as  can  possibly  be 
brought  into  it. 

2.  One  day  of  each  DIS++  conference  will  be  devoted  to  user  community  forums.  These 
forums  will  be  excellent  vehicles  for  the  continuing  development  and  support  of  DIS++ 
products. 


Processes 
•  Question: 

The  processes  proposed  don't  appear  to  be  anything  special  and  don't,  on  the  surface,  appear  to  be 
that  much  different  from  before.  Are  they? 

Answer: 

In  many  ways  the  proposed  processes  are  a  formalization  of  processes  that  have  in  effect  for 
the  past  few  years.  In  the  early  days  of  DIS  the  conference  and  work  groups  were  small 
enough  to  effectively  develop  standards.  As  the  size  and  number  of  groups  increased  the  task 
of  standards  development  was  assigned  to  ad  hoc  teams  from  within  working  groups.  These 
teams  had  little  formal  guidance. 

The  separation  of  standards  development  activities  from  the  conference  and  the  establishment 
of  formal  processes  are  efforts  to  make  standards  development  more  efficient  and  more  ac¬ 
countable  in  the  large  community  that  DIS++  has  become. 


Information  Technology 

•  Question: 

Will  the  architecture  work  address  the  issue  of 'plug-ins'  for  DIS-h-h  compatible  software  to  allow 
new  protocol  elements  to  be  incorporated,  experimented  with  and  exploited  rapidly? 

Answer: 

There  is  nothing  planned  along  these  lines,  but  such  an  approach  will  not  be  precluded. 
Please  expand  on  this  issue  and  state  what  you  would  like  to  see  in  either  the  conference  or 
standards  development  structure  that  would  enable  such  a  capability. 
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■■""The  Way  Ahead ... 

THE  STEP  FORWARD 

The  Steering  Committee  for  the  Workshop  on  Standards  for  the  Interoperability  of  Distributed  Interactive  Simulations 
took  a  bold  step  forward  during  their  interim  meeting  on  12-13  February  1996.  After  an  in-depth  assessment  of  the 
current  workshop  direction  and  the  rapidly  emerging  baseline  definition  of  a  High  Level  Architecture  supporting  the  full 
spectrum  of  modeling  and  simulation  applications,  the  Steering  Committee  voted  unanimously  to  expand  the  scope  of 
DIS  to  include  all  modeling  and  simulation  application  domains.  In  so  doing  all  the  members  of  the  Steering 
Committee  made  the  following  commitment: 

‘The  DIS  Steenng  Committee  desires  to  support  the  entire  DOD  modeling  and  simulation  community 
with  a  set  of  standards  which  include  the  High  Level  Architecture  and  will  embark  on  whatever 
organizational  and  management  restructuring  is  required  to  accomplish  this.  ” 

This  commitment  recognizes  the  DOD  as  the  principal  sponsor  for  standards  development  but  does  not  in  any  way 
limit  the  expansion  of  sponsorship  across  a  wider  base. 

BENEFIT 

In  taking  this  step,  the  Steering  Committee  seizes  the  opportunity  for  implementing  the  “The  DIS  Vision”  prepared  in 
1994.  In  particular,  the  incorporation  of  the  High  Level  Architecture  fills  the  long  standing  void  expressed  in  the  vision 
document: 

“Foremost  among  the  technical  challenges  is  the  design  and  promulgation  of  a  comprehensive 
architecture.  A  well  defined  architecture  is  essential  to  provide  the  framework  for  the  application  of  DIS 
concepts...and....to  insure  independent  developers  apply  the  standards  in  a  consistent  manner." 

Moreover,  this  action  allows  expanding  the  standards  development  activities  to  serve  the  full  range  of  interest  of  the 
entire  modeling  and  simulation  community. 

TRANSITION 

A  Special  Task  Group  for  a  Vision  Implementation  Plan  (ST G  VI P)  has  been  formed  to  prepare  a  plan  for  transitioning  the 
current  standards  development  activities  to  meet  the  objective.  The  outline  of  the  plan  will  be  prepared  by  the  March 
1 996  workshop  followed  thereafter  by  an  initial  and  final  draft  version  at  six  week  intervals.  The  Coordinating  Committee 
along  with  others  they  may  select  will  serve  as  an  advisory  group  to  the  STGVIP.  Members  of  the  Steering  Committee 
along  with  others  from  communities  not  represented  in  the  current  standards  development  activities  will  be  asked  to 
provide  assistance  to  the  STGVIP  where  needed.  Provisions  will  be  made  for  public  review  and  comment  on  the 
transition  plan  as  it  develops. 

IMPLEMENTATION 

Implementation  of  “The  Way  Ahead”  will  begin  during  the  interim  meetings  held  following  the  14th  Workshop  and  in  the 
call  for  position  papers.  The  15th  workshop  in  September  1996  will  introduce  the  “new  look”  described  by  the  vision 
implementation  plan  with  the  full  implementation  being  complete  by  the  following  workshop. 

DIS-F+ 

We  have  chosen  “DIS++"  as  the  new  name  to  represent  our  expanded  scope.  In  selecting  the  name,  consideration  was 
given  to  DIS  97  to  emphasize  the  urgency  for  going  forward  and  DIS  2000  to  emphasize  the  breadth  of  investment  base 
which  will  rely  on  the  next  generation  of  standards.  However,  the  name  “DIS  ++”  has  been  selected  as  the  way  of 
communicating  the  essential  objective  of  expanding  the  standards  development  activities  to  include  both  the  High  Level 
Architecture  and  other  members  of  the  modeling  and  simulation  community 

HOW  TO  STAY  INFORMED 

Infonmation  regarding  status  and  progress  on  “The  Way  Ahead”  may  be  obtained  from  the  following  web  sites: 

STGVIP  Activities:  http :  //www .  sc .  ist  .ucf .  edu/-STDS/ 

HLA  Activities:  http://www.dmso.mil/projects/hla/ 

EMPLOYMENT  OPPORTUNITY 

Volunteers  will  be  needed  who  are  willing  to  take  on  new  challenges. 

Salary:  Negotiable,  as  long  as  it  is  in  multiples  of  zero. 

Job  Satisfaction:  Immense  to  those  who  revel  in  the  advancement  of  beneficial  technology. 

We  are  an  equal  opportunity  organization.  Current  workshop  participants  are  encouraged  to  hang  in  and  hang  on. 
Participants  of  all  modeling  and  simulation  persuasions  outside  the  traditional  DIS  community  are  encouraged  to  give 
employment  here  a  try. 
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